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A  Classification  Scheme  for  Software  Development 
Method^ 

V 

\) 

Abstract.  Software  development  methods  are  used  to  assist  with  the  process  of  de¬ 
signing  software  for  real-time  systems.  Many  such  methods  have  come  into  practice 
over  the  last  decade,  and  new  methods  are  emerging.  These  new  methods  are  more 
powerful  than  the  old  ones,  especially  with  regard  to  real-time  aspects  of  the  software. 
This  report  describes  a  classification  scheme  for  software  development  methods,  in¬ 
cludes  descriptions  of  the  major  characteristics  of  such  methods,  and  contains  some 
words  of  advice  on  choosing  and  applying  such  methods,  a 


1.  Introduction 

A  major  challenge  in  any  engineering  endeavor  is  taking  a  poorly  structured,  ambiguous,  incon¬ 
sistent,  incomplete,  and  oversimplified  requirements  specification  and  turning  it  into  a  well- 
structured  design.  It  is  especially  difficult  in  software  engineering,  a  new  field  with  few  standards 
and  procedures  to  act  as  guidelines  for  designers. 

This  report  is  one  of  a  series  concerning  the  classification,  assessment,  and  evaluation  of  soft¬ 
ware  development  methods  and  tools.  Its  purpose  is  to  describe  a  classification  scheme  for  soft¬ 
ware  development  methods  and  provide  relevant  background  material  about  these  methods.  In  a 
second  report,  the  assessment  criteria  for  software  development  methods  are  developed,  and  a 
third  report  describes  both  a  classification  scheme  for  tools  and  evaluation  criteria  for  selecting 
appropriate  ones.  Future  reports  will  apply  the  classification  scheme  and  assessment  criteria  to 
particular  methods  and  tools,  f  ■  )  ^ _ 

This  report  is  directed  to  th-ee  distinct  audiences:  those  who  write  software  requirements,  those 
who  design  and  implement  software  systems,  and  those  who  build  tools  to  automate  develop¬ 
ment  methods.  The  people  whom  we  expect  to  derive  the  most  from  this  report,  however,  are 
those  designers  and  implementors  whose  task  is  to  choose  methods  and  supporting  tools  for  use 
in  a  specific  application  domain. 

Since  one  of  the  stated  goals  of  the  Real-Time  Methodologies  Project  is  to  look  at  methods  and 
tools  associated  with  real-time  systems,  this  report  begins  with  a  context  chapter,  which  first 
describes  some  important  characteristics  of  real-time  systems  and  then  goes  on  to  describe 
some  of  the  conceptual  issues  that  motivated  us  in  this  endeavor.  Chapter  3  discusses  the 
classification  scheme  for  software  development  methods.  Chapter  4  describes  some  of  the  is¬ 
sues  in  the  development  process,  Chapter  5  provides  a  background  on  methods  and  their  char¬ 
acteristics,  and  Chapter  6  discusses  some  of  the  issues  relating  to  automated  support  of  the 
methods.  Finally,  the  last  two  chapters  describe  how  to  choose  and  apply  methods. 
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2.  Context 


When  people  use  the  term  software  design  method,  they  often  have  a  particular  aspect  of  the 
total  design  in  mind.  Our  definition  of  this  term  is  a  broad  one:  start  with  a  rather  sparse  set  of 
requirements  gathered  into  a  requirement  specification  and  derive  a  validated  implementation  of 
these  requirements.  The  emphasis,  however,  is  on  the  development  of  the  target  software,  with 
minor  references  to  the  additional  software  needed  for  successful  testing,  installation,  trouble¬ 
shooting,  and  quality  assurance  of  the  target  software.  One  of  the  drawbacks  of  discussing  soft¬ 
ware  development  as  an  abstract  activity  is  that  it  tends  to  give  a  mechanistic  view  of  the  design 
process,  while  most  practitioners  would  emphasize  the  contribution  of  individual  designers 
[Brooks  87].  We  agree  with  this  position,  and  we  reference  the  ideas  of  such  practitioners  to 
balance  the  more  simplistic  parts  of  this  study. 


2.1.  Characteristics  of  Real-Time  Systems 

Before  discussing  methods  of  design,  it  seems  judicious  first  to  lay  out  some  characteristics  of 
real-time  systems.  This  is  not  meant  to  be  a  complete  list  of  such  characteristics,  but  rather  a 
short  list  of  the  major  aspects  that  must  be  considered.  Uncontroversial  characteristics  such  as 
maintainability  and  quality,  which  apply  to  all  systems,  are  not  listed. 

1 .  The  major  characteristic  of  real-time  systems  is  that  many  different,  interacting 
functions  have  severe  performance  requirements,  especially  in  response  time  to 
events.  Other  functions  monitor  and  control  continuous  processes,  have  strict 
periodicity  requirements,  and  need  specified  computational  resources  within  strict 
time  intervals.  These  requirements  are  exacerbated  by  the  need  to  respond  to  sud¬ 
den  “bursts"  of  events  on  top  of  the  regular  processing  capability. 

2.  Real-time  systems  interact  with  various  tensors  and  emitters,  which  transmit  to 
the  computer  system  signals  representing  the  state  of  the  environment  and  convey 
control  signals  to  effect  the  environment.  These  devices  may  input  analog  measure¬ 
ments  (temperature,  speed,  flow-rate),  output  analog  values  (setpoints),  input  digital 
measurements  (on/off  status  of  devices),  or  output  digital  signals  (open/close 
switches). 

3.  Real-time  systems  are  almost  always  resource  constrained.  In  some  cases  the 
systems  are  CPU  bound:  in  others  main  memory  allocation  is  the  problem;  and  in 
yet  others  the  bottleneck  occurs  in  communications  between  distributed  compo¬ 
nents,  access  to  shared  data,  or  access  to  secondary  storage.  Unfortunately,  con¬ 
cern  with  one  resource  (such  as  CPU)  often  leads  to  an  implementation  in  which 
another  resource  (such  as  memory)  becomes  a  severe  bottleneck,  necessitating 
large  redesign  efforts. 

4.  Real-time  systems  are  event  driven,  and  large  parts  of  their  behavior  can  be  de¬ 
scribed  as  responses  to  events  in  the  environment.  Capturing  the  interaction  of  the 
system  with  the  environment  is  itself  an  important  aspect  of  the  design.  In  real-time 
systems,  the  behavior  of  these  responses  to  different  events  must  be  synchronized. 

5.  Real-time  systems  often  control  and  monitor  systems  that  are  continuously  in  oper¬ 
ation  and  cannot  afford  downtime  due  to  failure  conditions;  hence,  fault  tolerance 
is  required.  This  has  important  software  design  consequences  for  recovery  of  func¬ 
tions  without  loss  of  time  or  critical  information. 

6.  Some  real-time  systems  must  be  in  operation  continually.  Software  may  have  to  be 
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installed  on  a  standby  system,  with  an  enforced  switchover  of  control  to  the 
standby  when  the  change  has  been  installed.  The  system  which  was  previously  in 
control  can  then  be  upgraded  and  placed  into  operation  in  a  backup  mode. 

7.  Real-time  systems  are  difficult  to  debug  in  the  target  environment  because  the 
delivered  system  may  have  residual  flaws  that  have  not  been  detected.  Often  the 
direct  symptoms  from  these  flaws  are  too  obtuse  to  trace  and  correct.  Hence  the 
software  design  should  include  some  tailorable  data  extraction  capability  to  yield 
sufficient  secondary  symptoms  to  isolate  and  correct  flaws. 

8.  Because  real-time  systems  are  usually  installed  into  an  operating  environment  dif¬ 
ferent  from  the  development  environment,  a  set  of  problems  can  arise  during 
installation.  The  software  design  has  to  allow  for  easy  installation  of  the  system 
and  for  procedures  to  validate  the  operational  capability  of  the  installed  system. 

9.  Software  is  such  a  major  part  of  the  current  generation  of  real-time  systems  that  the 
interactions  between  the  software,  hardware,  and  the  human  operator  need  to  be 
thoroughly  inspected  for  failure  modes  that  can  lead  to  hazardous  operating  con¬ 
ditions.  Thus,  some  care  must  be  taken  for  software  safety  conditions  (Leveson 
83]. 

1 0.  Department  of  Defense  (DoD)  real-time  systems  operate  in  an  evolving 
environment.  Software  changes  are  necessitated  by  changes  to  the  threat  environ¬ 
ment,  to  operational  procedures,  and  to  hardware.  The  design  method  should  in¬ 
clude  an  evaluation  of  the  most  likely  ways  the  environment  will  change  and  also 
encourage  a  software  partitioning  strategy  which  can  best  accommodate  such 
changes  [Pamas  86]. 

There  is  a  wide  range  of  real-time  systems,  varying  from  firmware  in  a  small  chip  with  limited 
input/output  and  no  persistent  data,  to  systems  supporting  all  battlefleet  operations.  Some  are 
control-flow  oriented,  others  have  a  large  number  of  varied  persistent  objects,  and  still  others  are 
dataflow  oriented.  In  very  large  systems,  portions  of  the  system  will  contain  components  with  all 
of  the  above  characteristics.  There  is  probably  no  single  method  which  is  "the  best"  for  the  com¬ 
plete  range  of  real-time  systems. 


2.2.  Conceptual  Issues 

In  deriving  a  classification  scheme  for  software  design  methods,  we  addressed  some  of  the  con¬ 
ceptual  issues  described  below. 

1 .  How  well  does  the  method  expose  the  flaws  in  the  requirements  and  help  the  desig¬ 
ner  create  a  consistent  and  correct  specification?  How  strictly  can  the  method 
validate  the  specified  functionality  and  behavior  at  the  early  stages  of  represen¬ 
tation?  How  does  the  method  handle  the  performance  and  resource  constraints 
specified? 

2.  What  is  the  relationship  between  the  life-cycle  models  of  software  design,  the  differ¬ 
ent  stages  of  representations  of  the  software,  and  the  activities  performed  by  the 
designer? 

3.  What  is  the  Interaction  between  different  representations  of  the  software,  and  how 
can  we  use  the  higher-level  representation  to  help  derive  the  lower-level  one?  If 
there  is  minimal  carry-over  between  levels,  is  it  worthwhile  going  into  great  detail  at 
the  higher  level? 
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4.  At  what  points  in  the  design  process  are  human  intelligence,  judgment,  and  deci¬ 
sion  making  most  important,  and  why?  What  heuristics  do  good  designers  use 
when  developing  a  design? 

5.  How  can  a  design  at  one  level  be  communicated  to  audiences  with  different  roles  to 
play  in  the  development?  The  design  is  usually  produced  by  a  small  group  of 
people  and  used  by  a  much  larger  audience;  therefore,  there  should  be  a  "reader- 
oriented"  representation.  What  aspects  of  design  are  particularly  difficult  to  deal 
with? 

6.  How  can  we  represent  the  design  so  that  changes  defined  at  a  high  level  can  be 
easily  incorporated  through  all  levels  and  eventually  be  incorporated  into  the  target 
system  al<  in  a  disciplined,  uncomplicated  manner? 

7.  How  can  the  design  method  best  build  upon  previous  work  done  by  others,  includ¬ 
ing  reuse  and  salvaging  of  parts  at  all  stages  of  representation? 

8.  Where  do  tools  play  their  most  useful  role? 

The  intent  of  this  project  is  to  look  at  well-established  and  supported  design  methods.  There  are 
many  such  methods  currently  in  use,  and,  in  some  cases,  there  are  many  commercial  tool  sets 
available  that  automate  some  aspects  of  a  single  method  (for  example,  structured  analysis). 
Some  vendors  are  also  extending  the  capability  of  the  original  methods  in  their  automated  tool 
sets  (for  example,  incorporating  state  transition  diagrams  with  structured  analysis).  However, 
there  is  also  a  significant  body  of  research  that  examines  certain  aspects  of  software  design,  and 
we  cannot  help  but  be  influenced  by  this  research,  especially  in  the  area  of  developing  criteria  for 
good  methods.  The  most  relevant  research  areas  are  those  of  formal  methods  and  artificial  intelli¬ 
gence.  The  work  on  formal  methods  is  oriented  toward  specification  of  the  design  using  math¬ 
ematical  representations  such  as  CSP  (Hoare  85],  [Hayes  87],  VDM  [Bjorner  82],  or  specification 
languages  with  an  underlying  theory,  such  as  Larch  [Guttag  85],  The  work  on  artificial  intelli¬ 
gence  is  oriented  toward  automatic  programming  [Balzer  85],  wide-spectrum  languages  [Smith 
85],  and  transformations  [Partsch  83].  While  these  and  other  efforts  are  undoubtedly  important 
research  developments,  evaluating  their  capabilities  is  not  the  major  concern  of  this  project. 
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3.  Classification  of  Methods 


In  this  chapter,  we  discuss  classification  of  design  methods.  We  introduce  the  classification 
scheme  here  to  lend  a  focus  to  the  remainder  of  the  report  and  to  explain  why  certain  issues  are 
given  only  cursory  attention.  We  first  introduce  the  two  independent  axes  of  the  classification. 
Then  we  discuss  the  classification  scheme.  More  detailed  historical  perspectives  of  methods  are 
included  in  later  chapters. 


3.1.  Software  Development  Stages 

The  development  stages  are  listed  below.  Each  development  stage  is  characterized  by  the  as¬ 
pects  of  the  system  that  the  stage  represents  and  the  way  those  aspects  are  represented. 

The  requirement  is  a  description  of  what  the  end-user  audiences  view  as  their  needs  and  is 
often  a  rather  eclectic  description.  It  usually  covers  the  needs  of  each  audience  in  the  end-user 
community  in  an  uneven  manner,  with  some  aspects  (such  as  ease  of  installation)  often  over¬ 
looked.  It  often  describes  some  functions  (such  as  a  scheduling  mechanism)  in  very  general 
terms,  but  others  (such  as  a  communications  protocol),  extremely  thoroughly.  Often,  important 
requirements  are  not  addressed  in  the  requirements  specification,  and  they  need  to  be  exposed 
and  handled  as  they  arise.  The  earlier  these  issues  are  addressed  and  resolved,  the  better  the 
prospect  of  delivering  a  high-quality  product  within  budget  and  schedule. 

1 .  The  first  step  is  to  take  the  ambiguous,  incomplete,  and  inconsistent  requirement 
and  turn  it  into  an  almost  flawless  specification.  The  specification  describes  what 
the  software  is  to  do  and  the  constraints  to  be  imposed  on  the  designers.  Although 
the  design  process  is  not  the  primary  consideration  in  this  paper,  it  is  worthwhile 
noting  that  production  of  the  specification  is  not  limited  to  a  front-end  activity,  but 
will  proceed  throughout  the  life  cycle  of  the  system. 

2.  The  design  representation  describes  how  the  system  is  structured  to  satisfy  the 
specification.  It  describes  the  system  in  a  large-grained  manner  and  defines  the 
breakup  of  the  system  into  major  tasks.  It  describes  persistent  data  objects  and 
their  access  mechanisms,  the  important  abstract  data  types  and  their  encapsulation 
in  the  tasks,  and  the  message  structures  between  the  tasks.  There  must  also  be 
some  consideration  for  allocating  resources  and  satisfying  the  performance  require¬ 
ments. 

3.  The  final  development  stage  is  Implementation  with  source  code,  object  code, 
resource  usage,  and  initialized  data  structures.  This  is  the  level  at  which  algorithms 
are  developed  and  represented  explicitly. 


3.2.  Views  of  the  System 

Various  vlewu  of  the  system  are  needed  to  describe  Its  intended  and  actual  operation  [Harel  86). 

These  views  are  relevant  at  each  stage  of  the  system  development  and  are  enumerated  below. 

1.  The  functional  view  shows  the  system  as  a  set  of  entities  performing  relevant 
tasks.  This  view  Includes  a  description  of  the  fask  performed  by  each  entity  and  the 
Interaction  of  the  entity  with  other  entities  and  with  the  environment.  The  functional 
view  is  often  the  starting  point  for  the  design  process,  since  it  is  commonly  the  way 
the  system  is  decomposed  into  smaller  and  sinpler  parts. 
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2.  The  structural  view  shows  how  the  system  is  put  together:  the  components,  the 
interfaces,  and  the  flow  between  them.  This  view  also  shows  the  environment  and 
its  interfaces,  and  information  flows  between  it  and  the  system.  Ideally,  the  struc¬ 
tural  view  should  be  an  elaboration  of  the  functional  view.  Each  entity  in  the  latter 
view  is  decomposed  into  a  set  of  primitive  software  components  that  can  be  imple¬ 
mented  separately  and  then  combined  to  build  the  entity.  The  design  process, 
therefore,  generally  converts  a  functional  view  into  a  structural  view.  However,  the 
structure  of  a  system  is  influenced  by  resource  constraints  which  prevent  the  use  of 
arbitrarily  many  or  arbitrarily  large  components.  The  structure  is  also  influenced  by 
certain  implementation  constraints  that  require  the  use  of  specific  types  of  compo¬ 
nent  (e.g.,  Mil-Std-1 750a  processors)  or  require  that  components  be  connected  in  a 
specific  manner  (e.g.,  by  Mil-Std-1553  buses).  The  structural  view  should  include  a 
definition  of  the  number  and  dimensions  of  entities  to  allow  for  resource  estimates. 

3.  The  behavioral  view  shows  the  way  the  system  will  respond  to  specific  inputs: 
what  states  it  will  adopt,  what  outputs  it  will  produce,  what  boundary  conditions  exist 
on  the  validity  of  inputs  and  states.  This  includes  a  description  of  the  environment 
that  produces  the  inputs  and  consumes  the  outputs.  It  also  includes  constraints  on 
performance  that  are  imposed  by  the  environment  and  function  of  the  system. 
Real-time  systems,  especially,  have  performance  requirements  as  an  essential  part 
of  their  correct  behs  r.  The  behavioral  view  should  include  a  definition  of  the 
expected  workload  and  the  required  responses  of  the  system  to  this  workload. 


3.3.  Classification  Scheme 

The  classification  scheme  shown  in  Table  3-1  uses  the  system  stages  (specification,  des  jn, 
implementation)  on  one  axis,  and  the  views  of  the  system  (behavioral,  functional,  and  structural) 
along  the  other  axis.  The  requirements  analysis  stage  is  not  included,  since  it  is  informal,  and  we 
believe  there  is  little  to  be  gained  by  including  it.  A  method  will  be  classified  by  marking  the 
appropriate  box  or  boxes.  A  later  report  will  further  detail  this  classification  scheme. 
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4.  Development  Process 

To  describe  development  methods,  we  must  also  describe  some  related  development  process 
issues.  This  chapter  outlines  the  issues  we  believe  are  important  in  the  development  process  and 
includes  discussions  on  systems  engineering,  system  and  software  life  cycles,  development 
paradigms,  and  management. 


4.1.  System  Design  Phases 

There  are  three  phases  in  the  development  of  large  military  systems  as  described  in  DOD-STD 
2167  —  concept  exploration,  demonstration  and  validation,  and  full-scale  development.  A  short 
summary  o'  each  is  given  below. 

1 .  The  concept  exploration  phase  (CE)  is  a  study  of  the  technical  feasibility  of  the 
system  in  which  each  contributing  technology  (and  science)  is  examined  to  deter¬ 
mine  how  it  is  applicable  to  the  system  being  considered  and  to  advance  the  tech¬ 
nologies  as  necessary  to  make  the  system  feasible. 

2.  During  the  demonstration  and  validation  phase  (DEMVAL),  the  applicable  tech¬ 
nologies  a*e  integrated  in  a  loosely  coupled  manner  to  demonstrate  the  feasibility  of 
the  system.  The  demonstration  is  not  necessarily  a  full-scale  model,  but  may  dem¬ 
onstrate  that  critical  parts  of  the  system  work  separately  and  that  the  technology  to 
integrate  them  exists. 

3.  During  the  full-scale  development  phase  (FSD),  design  systems  are  built  by  build¬ 
ing  upon  the  appropriate  technologies  from  the  DEMVAL  phase. 

The  software  developers  should  use  a  method  at  each  phase  appropriate  for  that  phase.  For 
example,  software  developed  for  the  concept  exploration  (CE)  phase  will  not  have  to  be  sup¬ 
ported  over  an  extended  period  of  time  to  the  same  extent  as  software  in  the  FSD  phase.  Hence, 
a  development  technique  lacking  a  maintenance  emphasis  may  be  appropriate  for  this  phase,  t"t 
is  totally  inappropriate  for  the  FSD  phase,  in  which  maintenance  is  a  primary  concern. 

Since  the  phases  also  have  very  different  objectives  and  may  be  widely  separated  in  time,  it  is 
unlikely  that  there  is  much  direct  carryover  of  software  artifacts  between  phases,  though  one 
should  not  discard  useful  DEMVAL  software  which  is  applicable  to  FSD.  This  is  especially  true  of 
software  environments  and  tools  which  have  been  developed  during  DEMVAL  and  can  be  used 
directly  in  the  development  of  FSD  software.  It  is  less  likely  that  application  software  produced  for 
the  DEMVAL  phase  can  be  used  directly  in  the  FSD  phase. 


4.2.  Systems  Engineering 

The  field  of  systems  engineering  involves  many  topics,  including  design,  installation,  and  opera¬ 
tional  aspects  of  a  system,  and  the  integration  of  different  artifacts  (hardware,  operational  soft¬ 
ware,  software  tools,  test  procedures,  operational  procedures,  and  maintenance  procedures). 
The  systems  engineer  has  to  understand  diverse  technologies  and  integrate  these  technologies 
into  a  well-designed  system  to  meet  end-users’  expectations.  Systems  engineering  is  usually 
performed  by  a  team  of  people  with  expertise  in  a  sufficient  number  of  the  relevant  areas  to 
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consider  the  requirements  and  constraints  associated  with  each  technology  of  interest.  They  are 
supported  by  experts  with  more  specialized  knowledge  in  each  technology  area.  A  list  of  typical 
technology  areas  is  given  below. 

•  sensor  technology 

•  human-machine  interface 

•  computer  processors  and  peripherals 

•  communications 

•  applications  domains 

•  fault  tolerance 

•  programming  languages 

•  operating  systems 

•  software  engineering 

One  of  the  most  difficult  problems  facing  the  systems  engineer  is  that  each  technology  is  advanc¬ 
ing  at  its  own  pace  (while  still  being  somewhat  dependent  on  the  other  technologies),  yet  the 
systems  eng!neer  has  to  choose  the  stage  of  each  technology  at  which  they  all  can  be  success¬ 
fully  integrated.  Thus  the  risk  of  having  out-of-date  technologies  is  balanced  against  that  of  not 
being  able  to  produce  the  system  on  time  and  within  budget.  (Of  course  the  software  engineer 
faces  the  same  problem,  with  a  somewhat  more  restricted  range  of  technologies.) 

The  systems  engineer  is  often  working  from  crude  estimates  of  both  the  workload  and  resource 
requirements  for  each  functional  component  of  the  system.  These  crude  estimates  are  made  from 
past  experience  and  are  greatly  aided  by  reusing  or  salvaging  both  hardware  and  software  (either 
the  artifacts  or  the  ideas).  Of  course  the  architecture  that  emerges  is  the  result  of  balancing  costs 
and  risks.  The  chosen  architecture  will  be  perceived  as  one  with  a  low  risk  of  bottlenecks  and  a 
high  potential  for  satisfying  the  functionality  within  the  prescribed  budget  and  schedule,  while  not 
gold-plating  the  solution. 

One  of  the  traditional  aspects  of  the  systems  design  is  to  specify  what  functions  will  be  provided 
by  hardware  and  what  functions  by  software,  as  well  as  how  the  software  modules  will  be  al¬ 
located  to  the  hardware  components  for  execution.  Systems  engineering  accounts  for  fault- 
tolerance  in  the  hardware,  describing  how  the  system  operation  is  affected  by  failure  of  hardware 
components.  The  systems  design  also  defines  how  the  communications  between  the  software 
executing  on  different  processors  will  be  achieved.  Systems  engineering  must,  therefore,  bo 
based  on  good  estimates  of  the  software  resource  requirements  In  order  to  assign  software  to 
hardware  components  and  to  make  sure  that  the  capacity  of  the  communications  channels  is 
sufficient  to  handle  the  data  and  signal  traffic.  This  has  always  been  a  difficult  task,  and  often  the 
resources  allocated  to  some  software  functions  were  insufficient,  or  the  channel  bandwidth  was 
inadequate,  or  the  storage  capability  of  the  media  was  inadequate,  and  so  on.  A  few  of  the  major 
drawbacks  of  such  a  design  philosophy  are  listed  below. 

•  The  software  design  often  reflects  the  hardware  design,  and  small  hardware 
changes  can  cause  significant  software  changes. 
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•  If  bottlenecks  arise,  a  reallocation  of  the  software  components  to  the  hardware  com¬ 
ponents  is  often  necessary,  hence  changing  the  software  design,  which  is  dependent 
on  the  hardware  configuration.  An  alternative  solution  is  to  include  hardware  with 
more  power,  but  this  often  leads  to  acquiring  new  operating  systems,  necessitating  a 
software  redesign. 

These  problems  with  this  approach  to  system  engineering  are  inherent  in  emerging  architectures 
such  as  PAVE  PILLAR  [PavePillar  85],  which  consists  of  both  loosely  coupled  and  tightly  coupled 
processor  clusters,  with  each  cluster  containing  special-purpose  processors,  general-purpose 
processors,  data  communications  channels,  and  signaling  communications  channels.  The  desig¬ 
ner  has  more  flexibility  to  assign  software  functions  to  processors,  but  the  assignment  is  difficult 
to  accomplish,  and  is  often  performed  in  the  later  stages  of  design  and  implementation. 


4.3.  Life-Cycle  Issues 

The  software  life  cycle  within  the  system  full-scale  development  (FSD)  phase  involves  managing 
and  controlling  the  software  acquisition  through  all  phases  from  requirements  analysis  to  deploy¬ 
ment  to  subsequent  maintenance.  DOD-STD  2167  describes  how  this  is  to  be  done,  and  clarifies 
in  its  foreword,  "The  intent  of  the  standard  is  to  permit  any  systematic,  well-documented,  proven 
software  development  methodology.  As  such,  this  standard  should  be  selectively  applied  and 
tailored  to  fit  the  unique  characteristics  of  each  software  acquisition  program,  and  the  particular 
life-cycle  phase  in  which  it  occurs."  The  life-cycle  activities  are  well  documented  in  the  standard 
and  in  other  reports  and  will  not  be  described  in  detail  here.  Unfortunately,  some  overloading  of 
the  term  phase  is  necessary  in  this  report  since  both  the  system  development  (EC,  DEMVAL, 
FSD)  and  the  software  development  portion  c*  FSD  use  the  word  phase.  For  the  remainder  of 
the  report,  phase  can  be  taken  to  mean  the  phase  of  the  software  life  cycle  within  FSD.  We  will 
specifically  use  "system  phase"  as  necessary. 

DOD-STD  2167  also  details  how  the  FSD  is  to  proceed.  The  standard  suggests  that  the  systems 
design  use  functional  decomposition  to  separate  the  system  into  software  and  hardware  configu¬ 
ration  items  as  a  first  step  during  the  software  requirements  analysis  phase  of  FSD.  This  devel¬ 
opment  paradigm  has  significant  problems,  some  of  which  are  detailed  in  [Firesmith  87],  and  it  is 
for  many  of  those  reasons  that  we  chose  to  take  an  approach  to  software  development  methods 
independent  of  life  cycle.  Further  reasons  are  listed  below. 

•  We  are  considering  development  methods  for  software  for  real-time  systems,  and 
the  emerging  technology  is  that  of  configurations  of  both  loosely  coupled  and  tightly 
coupled  processor  clusters.  Breaking  down  the  software  to  hardware  assignments  at 
an  early  stage  for  this  architecture  takes  away  the  software  designer's  flexibility  to 
assign  software  to  hardware  in  the  later  stages  of  the  design  cycle.  The  longer  the 
designer  can  postpone  such  physical  allocation  decisions,  the  greater  the  chance  of 
avoiding  bottlenecks. 

•  There  is  a  perceived  neod  to  describe  the  operation  of  the  system,  as  opposed  to  the 
software  components.  Many  specification  techniques  do  not  draw  rigorous  bound¬ 
aries  between  hardware,  software,  and  operational  requirements  at  an  early  stage 
but  concentrate  on  describing  what  the  system  must  do. 
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We  have  chosen  to  distinguish  between  development  stages  and  life-cycle  phases,  since  it 
makes  it  easier  to  understand  that  the  maintenance  phase  in  the  life  cycle  causes  changes  to  the 
representations  at  all  the  various  stages  in  the  development  process. 

There  is  an  ongoing  evolution  of  software  life-cycle  models.  The  most  commonly  used  model  is 
the  waterfall  model,  while  other  models  such  as  the  spiral  model  are  currently  being  proposed 
to  overcome  some  of  the  deficiencies  of  the  waterfall  model.  The  waterfall  model  [Royce  70]  is 
based  on  the  principle  of  completing  each  design  stage  before  going  to  the  next  stage,  although  it 
does  allow  for  feedback  to  corre 't  flaws  in  previous  stages  as  they  are  uncovered  in  later  stages. 
The  major  problem  with  this  apt  oach  is  that  its  uniformity  does  not  allow  the  designer  to  concen¬ 
trate  on  high-risk  issues  at  a  levul  low  enough  to  resolve  them.  The  spiral  model  [Boehm  86]  is 
an  attempt  to  improve  on  the  waterfall  model  by  allowing  designers  to  concentrate  on  tackling  the 
design  by  narrowing  it  to  the  remaining  high-risk  issues,  assuming  that  these  issues  can  be 
resolved  at  a  lower  level,  and  then  elaborating  on  the  solution  to  incorporate  more  of  the  function¬ 
ality.  The  spiral  model  continually  spirals  through  certain  activities  in  this  fashion  until  the  design 
is  complete. 


4.4.  Development  Paradigm 

The  previous  sections  made  no  mention  of  how  one  derives  representations  at  each  stage  and 
how  one  moves  from  stage  to  stage.  This  process  of  going  from  stage  to  stage  is  one  of  the  key 
issues  in  the  design  process  and  is  also  quite  controversial.  We  give  a  brief  description  of  each  of 
the  competing  pai  adigms  that  have  been  used  over  ihe  years. 

The  bottom-up  paradigm  is  often  used  in  two  slightl;  different  ways: 

1 .  To  denote  that  the  designer  leaps  from  requirements  to  implementation  descriptions 
of  how  to  solve  problems,  skipping  the  specification  portion,  and  dealing  only  in  a 
cursory  manner  with  the  design  stage. 

2.  To  denote  that  the  designer  identifies  the  low-level  functions  first,  designs  and 
implements  them,  and  then  proceeds  to  design  and  implement  the  next  higher 
level,  and  so  on. 

The  problem  with  either  interpretation  is  that  some  important  design  considerations  are  em¬ 
bedded  in  the  code,  and  if  these  are  incorrect,  they  lie  undetected  until  they  are  revealed  during 
system  integration. 

The  top-down  design  paradigm  usually  means  that  designers  start  with  a  single  representation  of 
the  system,  and  then  partition  the  system  by  some  scheme  (usually  functional),  describing  the 
interfaces  between  the  partitions  as  they  go.  This  paradigm  emphasizes  the  structural  and  func¬ 
tions'  viewpoints  as  opposed  to  the  behavioral  and  leads  to  designs  where  the  behavioral  aspects 
are  buried  in  the  code. 

In  the  mlddle-out  paradigm,  designers  reject  both  top-down  and  bottom-up  approaches  and 
proceed  by  choosing  some  aspect  of  the  sys'em,  specifying  it  thoroughly,  perhaps  making  a 
first-pass  design  to  determine  its  feasibility,  and  then  concerning  themselves  with  designing  de- 
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tails  of  interfaces  to  the  rest  of  the  system.  This  paradigm  has  an  added  advantage:  the  designer 
has  an  early  understanding  of  the  performance,  resource,  and  other  problems  associated  with  the 
design. 

The  rapid  prototyping  paradigm  describes  the  building  of  an  inexpensive  prototype  of  portions 
of  the  system  to  validate  the  requirements  before  committing  to  an  expensive  full-scale  produc¬ 
tion.  This  seems  to  be  a  good  way  of  approaching  both  the  high-risk  portions  of  the  system  and 
the  specification  of  user  dialogs. 

The  reuse  paradigm  is  currently  the  basis  of  extensive  investigations.  People  reuse  software  in 
two  principal  ways: 

1 .  Mathematical  and  statistical  library  functions  are  often  reused  without  giving  the 
subject  much  thought. 

2.  People  build  a  new  system  by  salvaging  what  they  can  from  a  known  and  similar 
previous  effort.  The  closer  the  new  system  is  to  the  previous  effort,  the  more  likely 
people  are  to  reuse  its  worthwhile  products. 

The  above,  however,  are  limited  examples  of  reuse,  which  is  now  seen  as  a  major  factor  in 
increasing  both  the  productivity  of  software  developers  and  the  quality  of  the  software  product. 

An  idealized  paradigm  is  one  in  which  the  designers  express  all  problems  completely  at  the 
specification  stage.  They  then  use  some  well-defined  procedures  and  heuristics,  supported  by 
powerful  tools  and  their  own  judgment,  to  derive  a  high-level  design  to  satisfy  the  specified  func¬ 
tionality  and  behavior  within  the  performance  and  resource  constraints.  Conventional  wisdom 
has  it  that  this  is  done  in  an  iterative  manner.  Prototyping  of  some  algorithms  is  necessary  to 
obtain  measurements  for  predicting  operational  performance  and  resource  usage:  recording  the 
design  in  a  top-down  manner  is  desirable  from  the  standpoint  of  reviewers  and  maintainers. 


4.5.  Management  Issues 

Software  engineers  produce  a  product  to  meet  a  set  of  users'  needs  and  to  be  used  by  people 
other  than  the  developers.  As  for  any  other  such  product,  the  definition,  design,  production,  and 
maintenance  require  management  of  both  the  people  developing  the  product  and  the  process 
being  used.  Management  issues  are  those  covering  costs,  schedules,  personnel  assignments, 
productivity,  and  coordination  and  communication  across  organizational  boundaries.  The  focus 
of  this  section  is  directed  at  the  overlap  of  methods  and  management  concerns. 

Methods  should  support  a  planning  process  that  Degins  with  the  development  of  a  definition  of 
the  system  to  be  built,  allows  for  the  early  examination  of  a  number  of  possible  designs,  and 
results  in  a  detailed  statement  of  what  will  be  produced,  when,  how,  and  at  what  cost.  To  support 
this  process,  methods  should  lead  to  artifacts  that  can  be  understood  and  reviewed  by  the  appro¬ 
priate  audiences.  The  methods  should  promote  rapid  development  of  high-level  design  represen¬ 
tations  that  can  be  analyzed  against  a  set  of  constraints,  compared,  and  judged  to  determine  the 
most  feasible  design  approach.  The  methods  should  prescribe  the  generation  of  a  sufficient 
number  of  intermediate  products  that  are  produced  at  a  reasonable  enough  frequency  to  support 
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the  creation  of  detailed  project  plans.  Schedules  and  budgets  presented  in  the  plans  should  be 
based  on  these  intermediate  products. 


Methods  must  integrate  with  the  process  of  organizing  and  staffing  a  development  project. 
Methods  prescribe  a  way  and  sequence  of  doing  things  —  what  activities  should  be  performed  in 
what  order.  Requirements  analysis  and  design  methods,  for  example,  often  lead  to  an  early 
partitioning  [see  Section  5.1 .3]  of  a  problem  into  manageable  pieces.  Projects  should  be  organ¬ 
ized  so  that  they  parallel  the  partitioning  prescribed  by  the  selected  methods.  Interrelationships 
between  subsystems  can  be  used  tu  identify  interrelationships  between  working  groups.  Partic¬ 
ular  characteristics  of  individual  subsystems  dictate  that  individuals  with  different  combinations  of 
skills  may  be  required  to  further  develop  each  subsystem.  Methods  are  not  substitutes  for 
individuals'  skills  but  can  help  identify  which  skills  must  be  developed  within,  or  acquired  by,  a 
particular  organization 

Methods  should  also  support  the  process  of  tracking  project  progress  and  controlling  ongoing 
activities.  The  methods  should  prescribe,  for  each  of  the  intermediate  products,  a  set  of  rules, 
metrics,  or  guidelines  that  can  be  used  to  judge  the  completeness  and  quality  of  the  intermediate 
products.  Review  teams,  using  these  rules  in  conjunction  with  their  own  knowledge,  should  be 
able  to  judge  the  status  of  each  intermediate  product.  These  judgments,  along  with  an  under¬ 
standing  of  the  relationship  between  intermediate  products  and  the  overall  project,  help  assess 
project  status,  pinpoint  areas  of  difficulty,  assess  risk,  and  focus  on  problem-correcting  activities. 
This  support  is  important  in  all  areas  of  development,  but  plays  an  especially  important  role  when 
♦he  methods'  intermediate  products  are  deliverables  in  a  contractual  sense. 

Finally,  methods  and  management  can  be  integrated  to  develop  an  understanding  of  the  engi¬ 
neering  process  within  a  particular  organization  and  help  direct  future  activities.  Use  of  methods 
on  projects,  including  the  activities  of  gathering  and  analyzing  data  on  the  use  of  the  methods, 
allows  an  organization  to  understand  its  strengths  and  weaknesses.  This  information  can  help 
identity  the  key  areas  where  skill  building  and  focused  management  activities  can  have  a  large 
payoff. 


4.6.  Audiences 

The  artifacts  associated  with  software  development  have  many  audiences,  each  with  its  own 
point  of  view  and  expertise.  This  means  that,  in  principle,  there  ought  to  be  various  views  of  the 
representations  available  for  perusal  by  each  specialized  audience. 

The  specification  of  what  people  do  can  be  divided  into  those  who  actively  create  the  represen¬ 
tations,  and  those  who  examine  the  representations,  with  the  recognition  that  some  people  do 
both,  or  perform  different  roles  at  different  stages.  The  major  audiences  are  outlined  below. 

1.  End-users  write  the  requirements  for  the  system,  and  will  install,  operate,  and 
maintain  the  system  after  it  is  delivered. 

2.  Specification  engineers  write  the  specifications  from  the  requirements,  resolving 
ambiguities,  removing  inconsistencies,  and  making  sure  that  the  specification  is 
complete.  They  should  specify  what  is  to  be  done,  not  how  it  is  to  be  done,  although 
in  some  areas  the  constraints  need  to  detail  the  implementation. 


16 


CMU/SEI-87-TR-41 


I 


3.  Software  designers  describe  how  the  software  is  to  be  constructed  to  satisfy  the 
specifications.  This  Involves  making  optimization  decisions  on  the  best  way  to 
proceed  given  the  constraints  imposed  in  the  specification.  Examples  of  such  con¬ 
straints  are  performance  requirements,  resources  available,  and  fault-tolerance  ca¬ 
pabilities.  These  constraints  often  influence  the  design  as  much  as  the  functionality 
and  behavior  of  the  system. 

4.  Algorithm  developers  have  specialized  knowledge  of  a  particular  engineering  dis¬ 
cipline. 

5.  Implementors  take  the  designed  products  and  produce  implementations  of  these 
designs. 

6.  Quality  assurance  people  make  sure  that  the  products  do  what  they  are  supposed 
to  do.  They  deal  with  the  quality  of  the  products  and  ways  of  managing  and  testing 
the  product. 

7.  Managers  are  concerned  with  providing  leadership  roles,  with  controlling  the 
budgets  and  schedules  related  to  the  project,  ensuring  that  problems  are  recog¬ 
nized  early  and  resolved,  and  dealing  with  the  various  personnel  assignments  and 
problems. 
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5.  Methods 


In  general,  a  method  is  "a  systematic  procedure,  technique,  or  mode  of  inquiry  employed  by  or 
proper  to  a  particular  discipline  or  art"  (Webster).  When  applied  specifically  to  software  engi¬ 
neering,  it  could  be  defined  as  a  systematic  approach  to  providing  a  software  solution.  The 
method  should,  ideally,  cover  all  aspects  of  the  problem  and,  in  the  context  of  software  engi¬ 
neering,  should  lead  from  an  initial  (imperfect)  set  of  requirements  to  a  satisfactory  implemen¬ 
tation,  passing  systematically  through  the  intermediate  stages. 


5.1.  Characteristics  of  Methods 

At  all  stages  in  the  development  process,  a  representation  of  the  system  must  be  created.  It  is 
important  to  understand  how  the  method  contributes  to  this  process.  The  method  of  designing  a 
system  at  any  stage  can  be  considered  from  three  points  of  view,  namely: 

1 .  What  is  the  form  of  representation  of  the  artifacts? 

2.  How  are  these  representations  derived? 

3.  How  are  these  representations  examined? 

Each  of  these  considerations  is  discussed  in  the  following  sections.  The  descriptions  are  not 
given  in  detail,  but  sufficient  information  is  supplied  to  give  the  flavor  of  the  approach.  The  char¬ 
acteristics  will  be  elaborated  in  a  further  report  describing  how  to  select  a  method. 

5.1.1.  Representational  Forms  of  the  Methods 

Chapter  3  described  the  proposed  classification  scheme.  The  most  important  characteristics  of 
the  representations  depend  on  the  stage  and  view  of  that  representation.  Some  common  charac¬ 
teristics  are  listed  below. 

1 .  Graphical  representations  are  much  easier  to  comprehend  and  are  used  to  convey 
the  understanding  of  the  specification,  design,  and  implementation.  They  also  as¬ 
sist  in  developing  a  design  and  are  most  useful  if  they  are  part  of  the  design  and  not 
just  explanatory.  Graphical  representations  prevent  developers  from  dealing  with 
detail  prematurely  and  allow  reviewers  to  perceive  patterns  more  easily.  Several 
problems  detract  from  this  comprehension  of  graphical  representations: 

•  clutter  arising  from  representing  too  much  information 

•  complexity  of  the  connections  between  objects 

•  difficulty  of  maintaining  connections  as  changes  arise 

The  alternative  textual  representation  has  the  advantage  of  being  more  detailed 
and  expressive.  In  general,  a  mixture  of  graphical  and  textual  information  is  desir¬ 
able.  The  textual  descriptions  provide  completeness,  and  the  graphical  represen¬ 
tations  provide  understanding  of  the  structures. 

2.  The  degree  of  formality  of  a  representation  is  also  important.  The  more  formal  the 
representation,  the  easier  it  is  to  reason  about  the  operation  and  decide  on  com¬ 
pleteness  and  consistency.  However,  a  formal  representation  can  obscure  the  “big 
picture"  by  its  concern  for  specifying  details.  The  formal  systems  are  also  more 
difficult  to  learn. 
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3.  A  large  system  has  to  be  partitioned  into  subsystems,  with  the  interfaces  between 
th^  subsystems  well  defined.  The  same  partitioning  scheme  should  be  applicable  to 
derive  a  multi-layered  representation. 

5.1.2.  Deriving  the  Representations 

A  method  must  not  only  describe  the  representations  produced  but  must  give  some  guidelines  for 
deriving  them. 

1 .  Designers  tend  to  use  past  experience  as  their  guideline  for  approaching  a  prob¬ 
lem.  They  pick  and  choose  from  their  experience  and  try  to  apply  to  the  current 
problem  their  knowledge  of  "what  works  under  which  circumstances."  Some  ex¬ 
amples  of  the  activities  they  perform  are  summarized  below. 

•  If  possible,  they  will  reuse  components  from  another  system,  since  this  is 
the  most  productive  path  to  take.  They  will  only  do  so,  however,  if  they  have 
access  to  these  components,  confidence  in  their  quality,  and  accurate  specifi¬ 
cations  of  their  functionality  and  cost. 

•  If  they  cannot  reuse  components  directly,  they  may  salvage  these  compo¬ 
nents,  picking  them  up  and  changing  them  to  apply  to  their  particular  prob¬ 
lem. 

•  Sometimes  they  cannot  reuse  or  salvage  components,  but  can  still  reuse  the 
design  principles  or  concepts  which  were  applied  previously  by  reorienting 
them  to  the  problems  of  the  design  at  hand. 

•  Sometimes  they  can  peruse  a  previous  design  and  determine  why  it  is  not 
appropriate  for  the  current  system  design.  This  often  leads  them  to  develop 
characterizations  for  the  new  problem. 

2.  Most  experienced  designers  have  an  "issues  list,"  either  on  paper  or  in  their  minds, 
when  they  approach  a  problem.  This  list  contains  important  issues  that  are  often 
overlooked  in  the  design  of  large  systems.  Their  critique  of  a  design  (their  own  and 
others)  is  often  based  on  their  consideration  of  one  or  more  of  these  issues.  Ex¬ 
amples  of  such  issues  are: 

•  Have  the  failure  conditions  and  recovery  characteristics  been  considered 
adequately? 

•  Have  the  performance  considerations  been  adequately  expressed? 

•  Have  maintainability  considerations  been  covered? 

3.  The  method  mjst  contain  clear  concepts  and  the  abstractions  necessary  to  de¬ 
scribe  thesu  concepts.  This  is  especially  true  at  the  high-level  design  stage.  For 
example,  the  specification  may  detail  many  related  but  different  objects  with  similar 
functionality  and  behavior.  It  is  the  designers’  responsibility  to  consider  these  as 
specializations  of  some  well-defined  abstraction,  since  it  is  usually  easier  to  deal 
with  as  few  concepts  as  possible  at  the  design  level. 

4.  Design  is  an  Incremental  activity  during  which  the  designer  creates  or  assembles 
parts  of  the  system,  examines  the  quality  of  the  artifacts  produced,  and  Iteratively 
changes  the  parts  to  add  more  functionality,  improve  the  performance,  improve  the 
interfaces  to  other  parts,  etc. 

5.  The  transformation  of  artifacts  from  one  stage  of  representation  to  another  is  ex¬ 
tremely  important.  A  separate  section  on  transformations  is  included  later. 

6.  The  representations  must  be  able  to  evolve  over  time,  since  software  evolves  in 
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response  to  changing  hardware,  operational  requirements,  and  added  functionality. 
Evolution  of  software  generally  retains  as  much  of  the  original  as  possible,  extend¬ 
ing  existing  representations  rather  than  developing  innovative  approaches,  and 
leaving  some  redundant  information  which  may  become  useful  later. 

5.1.3.  Development  Activities 

During  the  development  process,  the  design,  usually  in  a  state  of  transition,  is  inconsistent,  in¬ 
complete,  and  ambiguous;  even  its  feasibility  may  be  uncertain.  The  whole  purpose  of  a  design 
method  is  to  assist  the  developers  in  driving  the  design  toward  a  consistent,  complete,  and  un¬ 
ambiguous  representation  that  is  feasible  at  the  physical  level.  Design  usually  progresses  by  a 
series  of  activities.  These  activities  are  referenced  throughout  this  report  and  are  listed  below  for 
the  reader’s  convenience. 

1.  Partitioning  is  the  activity  of  breaking  a  large  problem  into  a  set  of  smaller  prob¬ 
lems  while  defining  the  interfaces  in  a  clear  enough  manner  to  maintain  control  over 
the  breakup. 

2.  Narrowing  occurs  when  designers  cannot  address  the  complete  partition  initially. 

They  ignore  certain  aspects  of  the  specification  until  they  have  a  design  for  a  por¬ 
tion  of  the  problem.  Once  they  have  the  par tial  design,  they  use  it  as  the  basis  for 
reintroducing  the  initially  ignored  aspects. 

3.  Elaboration  occurs  when  designers  add  more  functionality  to  the  partial  design.  If, 
for  example,  designers  ignored  recovery  issues  on  the  first  pass  of  a  design,  they 
would  be  elaborating  on  the  design  when  they  finally  include  the  recovery  require¬ 
ments.  Elaboration  occurs  at  a  new  design  layer  and  may  cause  changes  to  de¬ 
pendent  layers  already  created  in  the  original  design. 

4.  Refinement  is  the  process  of  including  more  detail  in  the  design.  For  example, 
expanding  a  node  in  a  data  flow  diagram  is  a  process  of  refinement.  This  process 
can  be  substantially  aided  by  using  an  already  existing  design  to  produce  a  for¬ 
matted  template  including  all  currently  available  information.  Refinement  is  the  way 
that  the  designer  usually  adds  new  layers  to  the  representation  at  the  same  stage. 

5.  Generalization  and  specialization  are  dual  activities.  Generalization  takes  many 
object  types  with  similar  characteristics  and  forms  a  generalization  containing  all  of 
the  common  attributes,  while  leaving  the  specialized  attributes  as  characteristics  of 
the  original  object  types.  Specialization  starts  with  a  single  object  type  and  derives 
different  object  types.  These  are  often  associated  with  the  so-called  Ts-a"  type 
lattice  structure,  and  are  more  powerful  if  the  specialized  objects  can  have 
exceptions.  (For  example,  a  penguin  is-a  bird  that  cannot  fly.)  These  activities 
allow  designers  to  describe  objects  and  the  behavior  of  operations  involving  those 
objects  at  the  appropriate  layer  of  abstraction. 

6.  Pruning  is  the  process  of  removing  functionality  from  the  product  being  designed. 

This  may  be  done  if  the  design  is  becoming  too  elaborate,  If  performance  require¬ 
ments  cannot  be  met,  or  if  the  overall  project  appears  to  be  Infeasible. 

7.  Transformation  is  the  process  of  taking  a  design  representation  at  one  stage  and 
transforming  it  into  the  representation  at  the  next  stage,  for  example,  transforming  a 
set  of  data  flow  diagrams  into  a  set  of  executable  processes  and  modules.  In  many 
cases,  transformation  cannot  be  done  automatically  but  requires  some  additional 
activities  by  the  designers. 

8.  Composition  occurs  when  fragments  with  well-known  attributes  are  synthesized  to 
perform  a  function  that  can  be  represented  at  a  higher  stage.  Composition  involves 
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customizing  an  assembly  of  components.  This  is  extremely  important,  since  it 
forces  designers  to  reuse  objects  with  well-defined  properties  and  to  salvage  and 
change  objects  that  almost  satisfy  the  requirements.  The  objective  is  to  improve 
both  productivity  of  the  design  and  robustness  of  the  assembly.  This  requires  the 
the  designer  be  aware  of  objects  at  a  lower  level  of  representation  in  order  to  com¬ 
pose  them  into  a  superior  level. 

9.  Examination  describes  the  ways  of  determining  the  validity  of  the  design,  and  it  is 
a  generalization  of  the  specific  activities  of  review,  inspection,  static  analysis, 
dynamic  testing,  and  rapid  prototype  building.  This  includes  analysis  of  represen¬ 
tations  at  the  same  stages  and  at  different  stages. 

1 0.  Enhancement  is  the  activity  of  making  changes  to  an  existing  design  to  change  its 
functionality,  improve  its  performance,  etc.  Enhancing  a  design  is  an  aggregation  of 
the  other  activities. 


5.1.4.  Examining  the  Representations 

The  usefulness  of  a  method  is  heavily  dependent  on  the  ways  available  to  examine  the  represen¬ 
tations  for  consistency,  completeness,  accuracy,  and  all  other  desirable  characteristics.  The 
sooner  problems  are  detected,  the  more  cheaply  they  can  be  fixed. 

1 .  We  can  use  formal  proofs  to  verify  a  system  completely,  but  this  method  is  not  a 
panacea  since  it  is  a  difficult  process,  understood  only  by  the  initiated,  and  unlikely 
to  be  accepted  by  the  end  user  without  some  other  representations.  Using  formal 
proofs  is  not  only  the  domain  of  the  well  trained,  but  it  is  also  difficult  and  time- 
consuming.  As  engineers,  we  should  expect  to  derive  some  heuristics  from  the 
formal  techniques  and  apply  these  in  practice. 

2.  There  are  many  ways  of  analyzing  the  different  forms  of  representation  for  com¬ 
pleteness,  consistency,  complexity,  and  coherency.  These  analytic  techniques 
have  three  basic  variations: 

•  analysis  of  the  same  representational  forms  at  the  same  stage  (though 
across  many  levels  and  partitions) 

•  analysis  across  different  representational  forms  at  the  same  stage 

•  analysis  across  different  stages  and  different  representational  forms 

It  is  clear  that  methods  supporting  powerful  analytic  capabilities  of  all  the  above 
categories  are  preferred  over  methods  with  less  substantial  capabilities. 

3.  The  ability  to  animate  the  representational  form  is  considerably  important,  since  it 
provides  immediate  responses  to  the  “what  if"  questions  concerning  the  response 
to  specified  operational  conditions  and  allows  the  design  to  be  improved  inter- 
ictively. 

4.  The  ability  to  execute  is,  of  course,  taken  for  granted  once  code  has  been  gener¬ 
ated  for  the  final  system,  and  all  testing  is  predicated  on  the  execution  of  the  coded 
system  in  its  final  environment.  One  of  the  major  problems  is  that  specification  flaws 
which  are  detected  in  this  manner  can  cause  significant  redesign  and  adversely 
affect  the  delivery  schedule  and  budget  for  the  system.  For  this  reason,  there  have 
been  attempts  to  create  executable  specifications  such  as  PAISLey  (Zave  86).  An 
alternative  method  is  to  produce  executable  rapid  prototypes  of  high-risk  keystone 
portions  of  the  system. 

5.  The  examinations  should  be  Incremental  to  allow  the  designer  to  examine  portions 
on  a  stand-alone  basis. 
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6.  The  ability  to  determine  the  quality  of  software  using  some  predefined  metrics  is 
extremely  desirable.  The  metrics  used  should  be  sufficiently  powerful  to  allow  the 
designer  to  select  between  alternative  designs,  and  sufficiently  simple  to  do  so  at  a 
high  ievel  of  abstraction. 


5.2.  Historical  Perspectives 


The  purpose  of  this  section  is  to  give  a  historical  perspective  of  specification  and  design  methods 
without  describing  details  of  individual  methods.  All  of  the  methods  referenced  are  listed  in  Ap¬ 
pendix  A  for  convenience  and  are  referred  to  below  only  by  acronym. 

The  development  and  evolution  of  methods  for  specification  and  design  are  interwoven  with  the 
changes  to  related  technologies  that  have  occurred  over  the  same  time  period.  To  give  a 
chronological  description  of  these  developments  is  an  imposing  task.  We  have  chosen  juct  to 
describe  the  major  influences. 

1 .  The  initial  motivations  for  developing  specification  and  design  methods  were  both 
administrative  and  technical.  From  an  administrative  point  of  view,  the  methods 
broke  the  systems  into  individual  pieces  at  different  phases,  stages,  or  levels.  Es¬ 
timates  of  various  types  could  then  be  made  about  the  pieces;  budgets  and 
schedules  could  be  generated,  monitored,  and  maintained.  From  a  technical  point 
of  view,  the  methods  curbed  a  tendency  to  go  directly  from  requirements  to  coding 
by  introducing  more  rigorous  specification  and  high-level  design  mechanisms.  One 
of  the  problems  with  the  initial  methods  was  that  products  were  often  deficient  with 
respect  to  some  technical  aspect  that  was  not  well  expressed  by  the  method,  for 
example,  performance  was  unacceptable,  or  there  were  insufficient  machine 
resources  to  support  operation  of  the  system  during  integration,  or  the  user- 
interfaces  were  unwieldy.  Such  deficiencies  often  necessitated  costly  redesign, 
causing  schedule  and  budget  overruns.  There  has  been  a  tendency  recently  to 
restore  this  balance  by  attempting  to  include  more  technical  aspects  into  the  meth¬ 
ods  while  still  improving  the  administrative  aspects. 

2.  The  emphasis  on  methods  has  come  from  the  data  processing  community,  and 
most  of  the  early  developments  were  specifically  for  that  applications  domain. 
Various  methods  were  developed  (JSD,  SA/SD,  SADT,  PSIVPSA)  that  were  ap¬ 
plicable  to  the  design  of  applications  programs  in  that  domain.  These  methods 
were  initially  developed  in  the  mid-1970s  and  have  been  slowly  evolving  to  incor¬ 
porate  new  ideas  and  to  respond  to  observed  weaknesses  in  practice.  One  of  the 
interesting  developments  over  these  same  years,  however,  is  that  very  good  and 
powerful  tool  sets  have  been  built  to  simplify  the  development  of  routine  operational 
aspects  from  this  applications  domain.  Examples  of  such  tool  sets  are  database 
management  systems,  fourth  generation  languages,  and  data  dictionaries.  These 
tool  sets  were  not  related  to  the  design  methods  used  previously  to  perform  these 
functions  using  operating  systems  files  and  programming  languages. 

3.  One  of  the  major  drawbacks  of  using  these  methods  was  the  burden  of  tedious 
details  to  be  checked  by  the  designer.  In  actual  fact,  most  designers  were  rather 
cavalier  about  those  details,  and  just  forced  things  to  fit  into  the  programming 
stages.  The  availability  of  workstations  with  bit-mapped  displays,  windowing  sys¬ 
tems,  and  access  to  laser  printers  has  spawned  much  automation  of  the  methods. 
Automation  transfers  much  of  the  tedium  from  the  designer  to  the  machine  and  will 
undoubtedly  improve  the  usability  of  the  methods  and  the  quality  of  the  results.  A 
more  detailed  discussion  of  automation  is  given  in  [Firth  87], 
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4.  From  the  experience  gained  in  using  the  methods  over  a  number  of  projects  and  a 
number  of  years,  the  methods  are  being  Improved  to  remove  some  of  *h«ir  weak 
points.  For  example,  although  top-down  descriptions  may  suit  readers  specifi¬ 
cations,  they  are  a  poor  process  for  creating  a  design.  Many  of  the  methu  Js  now 
recommend  a  midd'e-out  approach  to  the  design  process,  while  maintaining  the 
top-down  description  of  the  resulting  design. 

5.  Many  of  the  techniques  developed  for  the  data  processing  community  were  inap¬ 
propriate  for  real  time  systems,  which  are  more  oriented  toward  “response  to 
events  in  the  environment"  and  "periodic  processes"  than  to  transactions.  Hence 
they  require  an  effective  way  of  describing  this  response  and  its  interactions  with 
other  responses.  There  has  been  a  tendency  toward  using  methods  that  include 
behavioral  descriptions  at  the  specification  stage,  such  as  those  described  below: 

•  extending  established  methods  to  incorporate  state  transition  diagrams  de¬ 
scribing  behavior  [Ward  86] 

•  creating  new  graphical  methods  incorporating  multi-level  state 
machines  [Harel  86] 

•  using  formal  mathematical  descriptions  to  describe  the  behavior  [Hoare  85]. 

6.  The  concept  of  Information  hiding  was  introduced  in  [Parnas  72],  It  postulated 
that  each  software  module  should  have  direct  access  only  to  the  bare  minimum  of 
information  it  needs  for  execution.  Other  necessary  information  should  be  obtained 
by  accessing  modules  that  understand  the  data  structures.  This  led  directly  to  the 
so-called  A7  method.  There  was  also  some  related  work  done  on  the  Smalltalk 
environment  [Goldberg  84],  which  used  a  software  paradigm  of  treating  objects  as  a 
data  structure  and  a  set  of  access  mechanisms  to  that  structure.  These,  and  the 
work  done  on  abstract  data  types  [Aho  83],  have  led  to  the  object-orle  ^  design 
methods  that  are  being  used  (especially  with  Ada  as  the  target  langu.  an  ex¬ 
ample  of  which  is  described  in  [Booch  83a]. 

7.  The  original  development  methods  were  exclusively  interested  in  development  is¬ 
sues  and  had  little  involvement  with  the  software  life  cycle  or  other  quality 
assurance  aspects  of  the  software,  such  as  testing  and  integration.  This  has 
changed  dramatically,  and  there  is  an  emphasis  on  quality  assurance  and  life-cycle 
support  included  in  many  emerging  methods  (DCDS  and  TAGS). 


5.3.  Comparison  and  Classification  of  Methods 

There  are  numerous  surveys  [Yau  86],  classifications  ( [Hesse  84],  [Kelly  87],  [McDonald  85]), 
and  comparisons  ( [DoD  82],  [Bergland  81],  [Floyd  86])  of  development  methods.  Many  of  these 
papers  propose  classification  schemes  and  evaluation  criteria  for  methods.  While  we  agree  with 
most  of  the  individual  points  made  in  these  papers,  have  used  them  to  develop  our  own  classifi¬ 
cation  scheme,  and  will  lean  heavily  on  them  in  developing  our  evaluation  criteria,  we  feel  that 
their  proposals  are  not  entirely  appropriate  for  reasons  such  ab  those  listed  below. 

•  There  was  often  no  clear  distinction  between  classifying  methods  (describing  what 
methods  do)  and  evaluating  methods  (saying  how  well  they  do  it).  We  believe  this 
distinction  is  essential. 

•  We  believe  that  the  classification  scheme  has  to  be  simple  (but  meaningful),  though 
the  evaluation  criteria  should  be  extensive. 

•  The  classification  scheme  often  contained  a  curious  mixture  of  technical,  adminis- 
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trative,  and  economic  judgments.  We  believe  that  the  classification  scheme  should 
be  technical,  and  administrative  and  economic  considerations  should  be  evaluative. 

•  In  some  cases,  the  distinctions  were  purely  descriptive  and  would  be  difficult  to  use 
for  comparing  the  capabilities  of  different  methods.  For  example,  describing  one 
method  as  "data  flow"  and  another  as  "data  structure"  does  little  to  assist  in  classi¬ 
fying  the  methods. 

•  The  reports  were  often  selective  in  the  methods  chosen  (limited  to  three  to  five 
methods),  and  hence  there  was  less  need  to  define  general  classification  and  evalu¬ 
ation  criteria,  since  each  technique  could  be  probed  for  its  strengths  and 
weaknesses  individually. 

•  In  general,  the  papers  failed  to  assist  the  reader  in  assessing  the  usefulness  of  one 
method  over  another. 
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6.  Automated  Support 

This  chapter  describes  some  of  the  issues  Involved  with  automatic  support  for  the  software  devel¬ 
opment  process.  The  first  subject  discussed  is  tools  which  directly  support  the  development 
methods;  this  is  followed  by  a  description  of  the  capabilities  which  should  be  in  the  environments 
supporting  these  tools. 

6.1.  Tool  Support  of  Methods 

The  notion  of  using  tools  in  the  production  of  software  is  not  new.  Editors,  assemblers,  compil¬ 
ers,  linkers,  and  debuggers  are  examples  of  tools  that  are  widely  used  to  aid  the  soft  ire  engi¬ 
neering  process  during  the  implementation  phase  of  the  life  cycle.  A  classification  scheme  for 
such  tools  is  described  in  a  companion  report  [Firth  87].  However,  most  design  methods  can  be 
directly  supported  by  the  tool  functions  listed  below. 

1 .  Most  methods  provide  rules  or  heuristics  for  the  construction  of  products  and  the 
relationships  between  them.  Without  automated  tools,  a  designer  must  painstak¬ 
ingly  go  through  all  of  the  products  by  hand  and  perform  the  particular  analysis  to 
ensure  that  the  guidelines  are  being  strictly  followed.  An  automated  tool  can  check 
products  (either  while  they  are  being  produced  or  after  completion,  as  appropriate) 
to  ensure  that  the  method  is  being  applied  correctly.  The  extent  of  analysis  that 
can  be  performed  on  products  is  often  tied  to  the  formality  of  the  notation. 
"Consistency  checking  as  part  of  the  tool  is  often  limited  due  to  the  formality  of  the 
notation.  In  general,  connectivity  checks  are  performed,  and  Identified  items  are 
stored  in  a  so-called  data  dictionary.  Through  appropriate  naming  conventions, 
meaning  about  the  identified  objects  is  maintained"  [Dart  87]. 

2.  Compilers  have  been  traditionally  used  to  transform  textual  source  objects  written 
in  a  programming  language  into  objects  that  will  execute  on  a  particular  hardware 
and  software  suite.  Ever  since  compilers  have  come  into  common  usage,  there 
have  been  dreams  of  extending  this  compiler  paradigm  to  an  earlier  stage  in  the 
design  cycle  so  that  a  design  specification,  written  in  a  specification  language,  can 
be  transformed  by  a  "specification  level'  compiler  into  a  programming  language. 

There  are  many  aspects  to  this  subject,  and  a  great  deal  of  research  has  been 
done,  as  described  in  [Partsch  83]  and  [Balzer  85].  But  there  have  been  a  limited 
number  of  successes.  Although  this  work  has  yet  to  produce  commercially  viable 
products,  it  does  give  some  objective  criteria  for  evaluating  capabilities.  The  work 
raises  three  different  but  related  questions: 

•  How  can  we  best  represent  a  specification? 

•  How  can  we  effectively  transform  that  specification  into  a  satisfactory  design 
and  implementation? 

•  How  can  we  easily  make  changes  to  the  specification  and  derive  a  new  de¬ 
sign  and  implementation? 

The  state-of-the-practice  is  that  transformations  from  specifications  to  design  representations  are 
performed  by  programmers.  There  has  been  a  substantial  body  of  work  done  to  automate  certain 
well-defined  subsets  of  the  design  problem,  such  as  database  management  systems  (DBMS) 
[Date  86],  form  generators,  screen  painters,  and  report  writers.  These  are  the  so-called  fourth 
generation  languages  (4GLs),  which  would  be  more  appropriately  termed  application  generators 


I 


CMU/SEI-87-TR-41 


27 


and  are  described  in  [Raghavan  86].  These  have  been  developed  both  as  general  tools  to  be 
used  with  a  particular  commercial  DBMS  and  as  specialized  tools  associated  with  specialized 
applications. 

After  products  are  created  by  the  application  of  the  method,  it  may  be  necessary  to  manipulate 
(update  or  alter)  them.  With  hard  copies  of  the  products,  most  often  a  new  document  must  be 
created  to  replace  an  old,  insufficient  one.  An  automated  tool  can  make  copies  of  objects,  thus 
facilitating  alteration  of  an  object,  while  still  preserving  the  original  product.  Textual  or  graphical 
editors  can  support  fast  and  efficient  alteration  of  products.  Furthermore,  it  is  often  helpful  for  the 
designer  to  view  more  than  one  product  at  a  time.  Sometimes  the  designer  needs  to  trace 
through  or  view  a  group  of  products  that  are  related  in  a  particular  way.  An  automated  tool  can 
enable  the  designer  to  view  more  than  one  tool  output  by  windowing  techniques  which  enable 
switching  back  and  forth  between  a  number  of  different  references.  Searching,  sorting,  and  query 
facilities  may  also  be  provided  to  specify  related  objects. 

The  process  of  software  development  is  cyclic  in  nature  —  often  end  products  are  achieved  by 
iterations  of  the  same  process.  Automated  tools  aid  the  task  of  iterating  through  a  process  by 
maintaining  the  results  from  previous  processes,  performing  transformations,  and  providing  edit¬ 
ing  capabilities.  Using  a  tool,  the  designer  can  quickly  explore  different  ideas  that  originated  from 
the  same  starting  point.  In  the  case  of  user  interfaces,  a  tool  can  display  aspects  of  how  the 
end-product  software  might  behave.  Some  methods  also  contain  formal  executable  languages. 
The  execution  of  a  language  usually  results  in  some  form  of  analysis,  for  example,  to  point  out 
discrepancies  or  incorrectness  in  the  executable  specification.  The  tool  may  also  provide  facil¬ 
ities  for  visible  simulation,  e.g.,  animated  graphics,  which  can  be  a  good  means  for  communi¬ 
cating  to  the  user. 


6.2.  Tool  Consistency  with  Methods 

The  functionality  and  completeness  of  a  tool  must  be  weighed  against  the  impact  that  its  features 
have  upon  the  application  of  the  method.  Following  are  tool  features  that  can  help  or  hurt  a 
method: 

•  A  tool  can  be  used  by  a  wide  variety  of  organizations  and  users.  If  a  tool  can  be 
tailored  to  user  needs  or  to  a  particular  user  style,  the  tool  has  the  potential  to  be 
used  with  more  dexterity  and  at  a  faster  rate  than  would  be  otherwise  expected. 

When  a  tailorable  tool  supports  a  method,  it  is  also  important  to  understand  the 
ramifications  of  tailoring,  as  it  may  affect  the  application  of  the  underlying  method. 

This  not  only  may  affect  the  results  of  applying  the  method,  but  may  create  consid¬ 
erable  disparity  among  products  of  different  tool  users  on  team  projects. 

•  The  more  Intelligent  a  tool,  the  more  functims  it  will  perform  without  the  user  having 
to  directly  specify  its  initiation.  In  addition,  t  j  tool  should  be  helpful,  anticipating  the 
user  interaction  and  providing  simple  and  efficient  means  for  the  execution  of  func¬ 
tions  that  the  user  requires.  However,  the  tool  should  not  automatically  execute 
functions  that  may  interfere  with  the  design  process  and/or  the  application  of  the 
method  or  that  may  hinder  experimentation  by  the  user. 

•  A  tool  should  be  predictable.  The  user  who  is  already  familiar  with  or  trained  in  the 
method  the  tool  supports  should  not  be  surprised  at  any  action  or  output  of  the  tool 


28 


CMU/SEI-87-TR-41 


* 


supporting  the  method.  It  the  tool  has  omitted  or  changed  an  aspect  of  the  method  it 
supports,  an  experienced  user  of  the  method  can  become  frustrated  or  confused, 
thus  hindering  productivity. 

•  The  tool  should  be  flexible  and  able  to  support  the  method  enough  to  guide  the  user 
and  ensure  that  the  main  concepts  of  the  method  are  being  adhered  to.  However, 
the  tool  should  not  be  so  rigid  as  to  force  the  user  to  execute  steps  that  might 
possibly  be  done  at  a  later  time  or  omitted  completely. 

•  The  tool  should  be  robust,  never  generating  incorrect  transformations  or  executing  a 
faulty  analysis.  In  such  cases,  the  tool  seriously  hinders  the  designer's  work,  as 
these  mistakes  are  difficult  to  detect  and  locate. 


6.3.  Software  Engineering  Environment  issues 

The  environment  provides  capabilities  to  the  user  (designer  or  specifier  in  this  context)  and  to  the 
toolmaker.  The  environment  has  many  characteristics  which  support  both  of  these  audiences  and 
increase  their  productivity  and  the  quality  of  the  software  they  produce.  Some  example  environ¬ 
ments  are  listed  below. 

•  The  environments  provided  by  specific  operating  systems  such  as  Unix  and  VMS. 

•  Programming  language-dependent  environments  such  as  Cedar  [Teiteibaum  81], 
Smalltalk-80  [Love  83],  and  structure-oriented  environments  such  as  GANDALF 
[Habermann  86],  and  Rational  [Archer  86]. 

•  Environments  based  on  extending  current  operating  systems  and  including  database 
management  concepts  to  control  objects  and  relationships  between  objects.  Ex¬ 
amples  are  CAIS  [Mll-STD-CAIS  85]  and  PCTE  [Gallo  87], 

•  Environments  which  integrate  the  process  of  managing  software  products  and  the 
software  engineers  producing  those  products.  Examples  are  DCDS  [Alford  85], 

DSEE  [Leblang  85],  and  ISTAR  [Lehman  85]. 

It  is  not  the  purpose  of  this  report  to  carefully  inspect  the  issue  of  software  development  environ¬ 
ments;  however,  the  interested  reader  can  refer  to  [Dart  87],  [Houghton  87]  for  more  information 
on  the  subject.  It  is  our  intention  to  identify  what  characteristics  should  be  contained  in  the  envi¬ 
ronment  rather  than  in  the  tool  set  supporting  a  method.  These  characteristics  are  listed  below. 

1 .  The  environment  should  provide  a  set  of  common  user  Interfaces  which  the  user 
can  tailor  individually  and  which  give  a  common  way  of  operating  in  the  env  >ron- 
ment.  These  should  include  on-line  manuals,  "help"  capabilities,  and,  wherever  pos¬ 
sible,  iconic  and  graphic  support. 

2.  The  environment  should  allow  for  portability  of  tools  between  environments,  and 
for  the  interoperability  of  objects  produced  by  those  tools  between  environments 
and  between  tool  sets  within  an  environment. 

3.  The  environments  should  provide  object  management  such  that  the  objects  can 
be  stored  and  retrieved.  The  object  management  facility  should  support  a  rich  rela¬ 
tionship  between  objects  and  provide  the  user  and  the  tools  the  capability  to  browse 
through  the  object  base,  to  query  the  objoct  base,  and  to  produce  reports  about  the 
contents  of  the  object  base.  The  objects  In  the  object  base  should  be  heteroge¬ 
neous,  ranging  from  graphical  representations  to  executable  code.  The  object  man¬ 
agement  should  also  include  the  efficient  archiving  of  the  object  base,  and,  in  a 
distributed  system,  should  provide  location  transparency. 
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4.  The  environment  should  include  configuration  management  to  control  versions, 
configurations,  and  releases  of  the  objects. 

5.  The  environment  should  also  have  some  process  management  interfacing  with 
the  object  and  configuration  management.  Process  management  involves  control¬ 
ling  how  the  software  professionals  are  managed  to  produce  the  objects  according 
to  the  overall  objectives  of  the  organization  of  which  they  are  part. 

6.  The  environment  should  gather  data  concerning  the  workload  to  which  it  is  sub¬ 
jected  and  the  work  habits  of  the  users  (presumably  while  respecting  their  privacy). 

7.  The  environment  should  provide  mechanisms  for  access  authorization  to  objects, 
including  executable  objects. 
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7.  Using  Methods 

The  software  engineering  process  takes  a  requirements  specification  and  constructs  a  satisfac¬ 
tory  implementation  in  the  manner  previously  described.  The  process  is  governed  and  directed 
by  one  or  more  methods  that  prescribe  how  the  work  is  to  be  done,  the  stages  of  the  devel¬ 
opment,  and  the  actions  appropriate  to  each  stage.  Although  this  process  Is  usually  presented  as 
a  smooth  and  orderly  development,  in  practice  the  construction  of  real  software  rarely  ap¬ 
proaches  this  ideal.  For  example,  if  one  part  of  the  design  seems  to  involve  unusually  high  risk,  it 
may  be  appropriate  to  build  an  early  prototype  of  that  part  or  conduct  a  brief  feasibility  study  or 
performance  estimation.  The  design  method,  however,  might  require  that  all  parts  of  the  design 
be  brought  to  a  certain  stage  before  any  implementation  is  done. 

Another  reason  methods  cannot  always  be  applied  in  an  ideal  way  is  that  the  product  must 
adhere  to  rigorous  performance  or  size  constraints.  This  may  require  the  developer  to  be  con¬ 
cerned  with  optimization  issues  at  the  design  stage,  while  the  approved  method  might  require 
functional  issues  to  be  solved  before  performance  issues  can  be  addressed. 

For  these  and  other  reasons,  a  method  cannot  be  used  inflexibly  and  without  regard  to  the  overall 
circumstances.  Nevertheless,  most  methods  do  envisage  an  orderly  progression  from  require¬ 
ment  to  implementation. 


7.1.  Analyzing  Requirements 

The  requirement  is  a  description  of  what  the  user  wants.  It  excludes  many  of  the  details  which  the 
user  and  supplier  will  eventually  agree  upon  in  the  specification  and  serves  as  the  basis  for 
deriving  the  specification.  Before  proceeding  to  derive  the  specification,  however,  some  analysis 
of  the  requirements  is  necessary,  such  as  those  listed  below. 

•  identification  of  novel  areas  where  proof  of  concept  is  needed 

•  identification  of  high-risk  items 

•  prototyping  of  user  interfaces 

•  selection  of  an  appropriate  set  of  methods  for  the  remaining  stages 

•  selection  of  environment  and  tools  to  support  the  development  effort 

•  project  planning,  budgeting,  and  scheduling 

The  developer  and  user  can  be  helped  and  guided  by  a  method  for  requirements  analysis  that 
directs  their  attention  to  such  issues.  The  method  can  also  facilitate  the  planning  and  budgeting 
of  tasks  by  identifying  work  items  and  dependencies  at  an  early  stage. 
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7.2.  Deriving  the  Specification 

We  presume  that  the  method  of  specifying  the  system  has  been  determined  previously,  and  in 
this  stage  we  apply  this  method  to  the  requirements  and  derive  the  appropriate  specification.  The 
specification  states,  as  much  as  possible,  what  is  to  be  done,  not  how  it  is  to  be  done;  it  should 
include  the  entire  requirement  rather  than  the  more  limited  automated  portion  of  the  functionality. 
The  major  initial  activities  to  be  performed  are  enumerated  below. 

1.  The  specification  is  often  represented  in  a  top-down  manner,  but  it  is  rarely  derived 
that  way.  The  recommended  ways  of  proceeding  to  derive  the  specification  are  the 
middle-out,  object-oriented,  information-hiding,  event-driven  techniques.  As  ex¬ 
plained  in  [Parnas  86],  the  specification  can  still  be  represented  to  the  readers  in  a 
top-down  manner. 

2.  Identify  reusable  components  which  can  be  used  in  the  system.  These  can  be 
used  as  the  basic  building  blocks  around  which  the  system  is  to  be  constructed. 

They  can  then  be  used  as  constraints  on  the  specification  derivation  for  the  rest  of 
the  system.  Reuse  may  also  affect  the  requirements.  It  is  often  advantageous  to 
change  an  unimportant  requirement  if  doing  so  will  allow  for  the  reuse  of  available 
components. 

3.  Partition  the  problem  into  separable  subsystems,  each  with  its  own  specification 
team,  and  with  the  rules  for  interfaces  between  subsystems  well  defined. 

4.  Identify  aspects  which  overlap  subsystem  boundaries,  and  separate  them  into  one 
of  the  subsystems,  defining  interface  mechanisms  more  strictly.  This  usually  in¬ 
volves  the  process  of  generalization,  is  ongoing  throughout  the  specification  stage, 
and  is  especially  important  for  some  of  the  fundamental  specification  issues  such 
as  user  interfaces,  recovery,  fault  tolerance,  and  performance. 

5.  Develop  the  specification  for  each  subsystem  using  the  chosen  method,  remem¬ 
bering  to  account  for  the  weaknesses  of  the  method. 

6.  Concentrate  on  the  specification  of  the  previously  identified  high-risk  items,  and 
constantly  review  this  list,  update  it,  and  reassign  priorities  as  necessary. 

7.  Within  each  subsystem  or  portion  thereof,  specifiers  usually  start  by  narrowing  the 
problem  to  one  they  can  handle,  refining  the  specification  until  they  have  a  good 
grasp  on  the  details,  elaborating  on  the  problem  to  include  some  of  the  ignored 
aspects,  and  continuing  with  this  stepwise  refinement  until  they  have  a  completed 
specification.  Every  so  often  in  this  process,  they  have  to  remember  to  review  the 
interfaces  to  the  other  subsystems  and  to  pass  judgment  on  high-risk  items  under 
their  control. 

Although  the  specification  should  be  partitioned  to  make  it  most  easily  understandable  to  the 
various  audiences,  it  is  easier  to  maintain  traceability  between  the  specification  and  the  design 
artifacts  if  they  are  partitioned  in  a  similar  manner.  The  method  will  usually  control  both  the  way 
the  specification  is  partitioned  and  the  way  each  component  is  represented.  The  form  used  by  a 
method  to  represent  systems  and  components  Is  one  of  the  characteristics  that  allow  us  to  clas¬ 
sify  methods  as  discussed  in  Chapter  3. 
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7.3.  Identifying  the  Components  and  Structure 

The  specification  often  models  activities  to  include  operations  in  the  environment.  The  first  step  in 
the  design  process  is  to  identify  the  automation  boundary  for  each  relevant  portion  of  the  system. 
The  design  method  helps  here  by  providing  guidelines  for  how  this  boundary  is  to  be  drawn, 
procedures  for  specifying  in  a  more  formal  manner  the  interface  between  the  automated  system 
and  its  environment,  and  the  abstract  behavior  of  the  components  external  to  the  automated  part. 

Some  design  issues  involve  all  subsystems  and  components,  and  these  should  be  handled  first. 
In  particular,  issues  of  robustness,  fault  tolerance,  resource  consumption,  and  performance  in¬ 
volve  the  system  in  a  holistic  manner  and  cannot  be  cleanly  abstracted  into  specific  components 
or  specific  design  stages.  The  method  should  help  each  subsystem  designer  remain  aware  of 
issues  that  affect  all  parts  of  the  system. 

It  is  desirable  to  use  as  much  of  the  specification  level  description  as  possible,  especially  if  it  has 
been  refined  to  a  rather  detailed  level,  There  should  be  interactive  tools  to  allow  the  designer  to 
use  th8  specification  level  to  generate  the  design  level,  tools  to  check  for  consistency  between 
both  levels,  and  tools  to  analyze  whether  the  design  is  likely  to  satisfy  performance  requirements. 

There  is  a  need  to  look  at  subsystems  with  differing  but  similar  functionality  and  to  generalize 
them  if  appropriate.  It  often  happens  that  a  specification  defines  several  particular  objects  or 
functions  that  are  similar;  these  may  be  specific  examples  oi  a  general  case,  and  the  design 
method  should  recognize  and  exploit  such  generalities.  This  simplifies  the  construction  of  the 
system,  since  seemingly  special  components  can  be  recognized  as  instances  of  a  more  general 
component  that  might  already  exist  as  a  reusable  artifact.  It  also  helps  with  subsequent  enhance¬ 
ment  or  maintenance,  since  the  initial  implementation  offers  more  generality  than  originally  called 
for,  with  no  increase  in  complexity. 


7.4.  Implementing  the  Design 

Once  the  components  and  their  interfaces  have  been  fully  specified,  it  remains  to  implement 
them.  Some  methods  will  have  so  constrained  and  structured  the  design  process  that  subse¬ 
quent  implementation  is  almost  automatic:  the  design  has  been  driven  toward  using  a  set  of 
standard  primitive  components  for  which  generic  versions  are  already  available,  and  toward  inter¬ 
faces  whose  definition  can  be  constructed  from  a  functional  description.  Implementation  is  then  a 
matter  of  creating  specific  versions  of  the  components,  unit  testing  them,  and  integrating  them 
Into  larger  assemblies. 

Other  methods  leave  open  many  questions  of  implementation;  for  instance,  issues  of  the  physical 
representation  of  data  types,  the  exact  algorithms  for  data  transducers,  and  the  control  hierarchy 
of  the  code  components.  In  these  circumstances,  other  rules  must  be  used  to  guide  the  imple¬ 
mentation.  The  basic  problem  of  mapping  real-world  requirements  into  engineered  functional 
artifacts  is  a  hard  one,  one  which  most  methods  try  to  solve  by  restricting  the  design  space 
toward  paradigm  solutions  that  are  familiar  and  well  understood.  This  falls  when  the  problem  is 
truly  one  for  which  only  an  innovative  solution  will  work,  but  such  problems  are  perhaps  less 
common  than  usually  claimed. 
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Most  implementation  methods  specify  an  integration  and  test  strategy.  This  strategy  is  usually 
designed  to  allow  independent  interface  and  component  testing,  bottom-up  integration  testing, 
and  final  system  testing.  In  some  cases,  test  data  and  scenarios  will  have  been  derived  from  the 
formal  specifications. 

Finally,  many  methods  contain  techniques  for  improving  the  performance  of  a  system  once  built: 
optimization  techniques.  Once  a  system  has  been  tested  and  found  to  function  as  required, 
optimizations  reduce  its  size,  cost,  or  resource  consumption  without  changing  its  operation.  Op¬ 
timizations,  however,  sometimes  make  the  structure  of  the  system  less  obvious,  for  instance,  by 
combining  logically  separate  objects,  propagating  physical  information  across  a  logical  interface, 
or  reallocating  functional  units  to  balance  processing  requirements  or  minimize  physical  separa¬ 
tions.  When  this  is  done,  it  is  crucial  that  as  much  traceability  as  possible  be  retained  through  the 
transformations. 

7.5.  Summary 

When  software  developers  use  a  method,  some  tasks  are  almost  wholly  prescribed,  others  are 
guided,  and  still  others  are  barely  addressed.  The  use  of  a  method  must  therefore  judiciously 
combine  strict  adherence  to  rules,  informed  pursuit  of  guidelines,  and  tasteful  innovation.  A 
method  typically  helps  by  partitioning  the  problem  into  more  manageable  units,  providing  appro¬ 
priate  views  of  the  system  at  each  stage,  and  connecting  units,  views,  and  stages  together  in  a 
manner  that  preserves  traceability,  supports  analysis,  and  maintains  a  sound  development 
framework. 

As  discussed  previously,  the  assistance  of  specific  tools  can  be  invaluable  in  making  methods 
easier  to  use,  rules  easier  to  follow,  and  development  units  easier  to  manage  and  control. 


i 


8.  Choosing  Methods 

In  the  case  of  software  products,  the  following  must  occur:  "User  needs  and  constraints  must  be 
determined  and  explicitly  stated;  the  product  must  be  designed  to  accommodate  implementors, 
users  and  maintainers;  the  source  code  must  be  carefully  implemented  and  thoroughly  tested; 
and  supporting  documents  .  .  .  must  be  maintained"  [Fairley  85[.  In  addition,  the  engineering 
process  must  deal  with  real-world  constraints  that  limit  the  problem  solution  space  and  often  limit 
the  approaches  that  can  be  taken  in  the  process  of  transforming  the  requirements  into  an  accept¬ 
able  problem  solution. 

Software  development  methods  must  deal  with  more  than  the  process  and  techniques  that  trans¬ 
late  the  functional,  performance,  and  other  requirements  of  a  software  system  into  an  operational 
system.  They  must  deal  with  the  environment  that  exists  today  in  the  area  of  computers  and 
computing.  Software  engineers  with  diverse  backgrounds  and  training  are  asked  to  solve  prob¬ 
lems  with  wider  ranges  of  diversity,  increasing  complexity,  and  need  for  reliability.  They  must  use 
varying  implementation  languages  on  diverse  hardware  and  operating  system  platforms. 

The  process  of  choosing  methods  is  one  that  must  deal  with  the  problems,  goals,  and  situations 
alluded  to  above.  Earlier  work  on  methods  [McDonald  85]  indicates  that  method  evaluation 
should  be  based  on  a  three-step  process:  classification,  evaluation,  and  selection.  While  this  is 
true,  it  is  important  to  remember  the  overall  context  of  method  selection.  Methods  are  selected  to 
aid  the  solution  of  particular  problems  in  particular  situations.  The  process  of  selecting  methods 
in  support  of  the  engineering  of  software  must  be  based  on  the  following  activities. 

1 .  Analyzing  and  understanding  (classifying)  the  characteristics  of  the  engineering 
problem  to  be  solved,  the  nature  of  the  system  to  be  built,  the  constraints  on  the 
permitted  solution,  and  the  process  that  must  be  followed. 

2.  Analyzing  and  understanding  existing  methods  from  various  aspects:  technical, 
process,  usage. 

3.  Selecting  a  method  based  on  its  ability  to  help  the  engineers  who  will  use  it  to  deal 
with  the  problem,  the  solution  constraints,  and  the  engineering  process. 

The  rest  of  this  chapter  discusses  each  of  these  activities  in  turn  and  gives  an  overview  of  the 
issues  involved  in  selecting  methods.  Emphasis  is  placed  on  issues  dealing  with  the  engineering 
of  real-time  systems. 


8.1.  The  Engineering  Problem 

The  first  area  to  consider  when  choosing  a  problem-solving  method  is  the  nature  of  the  problem 
to  be  solved.  Engineers  who  develop  systems  must  deal  with  the  characteristics  of  the  system  to 
be  built  as  well  as  constraints  that  are  placed  on  the  software  implementation.  In  addition,  they 
must  follow  a  development  process  that  Is  defined  by  the  organization  in  which  they  work.  The 
following  subsections  discuss  these  areas  in  turn. 

1 .  System  characteristics.  Software  systems  are  called  upon  to  support  a  wide 
variety  of  applications,  and  each  system  generally  comes  with  its  own  unique  set  of 
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problems.  Individual  systems  can  generally  be  classified  into  one  of  several  cate¬ 
gories  (transaction  processing,  business  data  processing,  real-time,  etc.)  where 
members  of  each  category  share  a  common  set  of  characteristics.  An  understand¬ 
ing  of  the  nature  of  real-time  systems,  the  characteristics  they  have  in  common  with 
other  system  types,  and  the  characteristics  that  set  them  apart  is  the  first  step  in 
method  selection. 

Section  2.1  of  this  report  lists  characteristics  that  are  unique  to  real-time  systems. 
These  characteristics  are  important  to  consider  when  choosing  engineering  meth¬ 
ods  for  real-time  systems  in  that  the  characteristics  represent  especially  difficult 
problems  that  have  received  little  support.  Effective  methods  will  be  those  that  help 
the  engineer  deal  with  these  characteristics  as  well  as  those  that  are  common  to  all 
system  types.  General  characteristics  shared  with  other  types  of  systems  have 
been  described  in  [McDonald  85]. 

2.  Implementation  constraints.  The  characteristics  of  real-time  systems  present  the 
designers  and  implementors  of  typical  systems  with  a  set  of  difficult  problems.  Un¬ 
fortunately.  this  is  not  the  only  set  of  problems  that  must  be  considered.  In  many 
situations,  the  solutions  to  the  problems  are  constrained  by  the  available  technology 
and  by  the  needs  of  organizations  acquiring,  developing,  using,  and  maintaining 
systems. 

The  task  of  system  developers  includes  the  activities  of  analysis,  decomposition, 
and  understanding  of  the  systems  operational  requirements.  It  also  includes 
analyzing  and  understanding  the  solution's  constraints  to  compose  a  solution  that 
operates  within  those  constraints.  Effective  methods  must  support  and  preferably 
guide  developers'  efforts  to  compose  an  acceptable  solution  as  they  work  in  engi¬ 
neering  organizations. 

Software  solution  constraints  generally  fall  into  four  major  areas.  Detailed  discus¬ 
sion  of  many  of  these  characteristics  can  be  found  in  [Fairley  85]. 

•  Hardware  architecture  constraints:  These  are  generally  imposed  by  existing 
hs  '  vare  technology  as  it  relates  to  the  special  environments  in  which  the 
hardware  must  operate.  Real-time  systems  have  severe  performance  re¬ 
quirements;  they  need  reliability  in  harsh  environments  and  they  need  to 
sense  and  effect  conditions  in  the  external  environment.  These  needs, 
coupled  with  the  state  of  existing  hardware  technology,  create  hardware  plat¬ 
forms  with  special  characteristics.  Software  implemented  on  these  platforms 
must  account  for  the  special  characteristics. 

•  Software  architecture  constraints:  These  are  generally  imposed  by  the  need 
to  cost-effectively  create  and  maintain  software  that  operates  reliably  on  the 
constrained  hardware.  In  addition,  implementations  are  often  constrained  to 
use  "standard"  operating  systems,  language  systems,  and  existing  software 
components.  These  standards  are  often  imposed  with  the  goal  of  reducing 
the  complexity,  development  time,  and  life-cycle  f  ost  of  the  system. 

•  Integration  and  testing  constraints:  These  are  generally  imposed  by  perfor¬ 
mance  requirements,  time  pressures,  logistics,  and  economics  of  typicar  de¬ 
velopment  projects.  Software  integration  and  testing  are  often  overlooked  in 
discussions  of  development  methods,  but  testing  real-time  systems  is  an 
especially  difficult  task  that  should  be  supported  by  development  methods. 
Methods  used  to  develop  real-time  systems  must  support  the  process  of  inte¬ 
gration  as  well  as  test  case  generation,  test  execution,  and  analysis  of  test 
results.  They  should  aid  in  extrapolating  the  results  of  tests  executed  on 
hosts,  integration  systems,  and  target  system  simulators  to  predict  actual 
characteristics  of  the  software  on  the  real-target  hardware.  They  shot  ,r> 
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the  developers  understand  what  testing  can  validly  be  done  on  host  and  inte¬ 
gration  systems  and  what  areas  cannot  be  adequately  covered  using  this 
approach. 

•  Evolution  constraints:  These  are  typically  imposed  by  the  need  to  operate 
the  system  over  long  periods  of  time  and  to  Improve  the  system  over  its  life 
cycle.  Improvements  can  take  the  form  of  expanded  functionality  to  meet 
new  needs  or  the  form  of  an  enhanced  or  modified  hardware  platform. 
Hardware  platforms  are  often  modified  to  take  advantage  of  the  character¬ 
istics  of  newer  hardware  technology  that  provides  components  with  charac¬ 
teristics  such  as  greater  reliability,  decreased  weight  and  size,  or  lower  power 
consumption. 

3.  Process  constraints.  The  software  engineering  activity  occurs  in  the  context  of 
commercial  organizations  that  build  systems  for  profit.  In  addition,  the  systems  are 
acquired  by  commercial  or  government  organizations  that  need  to  solve  their  prob¬ 
lems  in  the  most  cost-effective  manner.  The  costs  to  consider  are  not  only  the 
costs  of  initially  acquiring  a  system,  but  also  the  costs  involved  with  operating  and 
maintaining  t1  ystem  over  long  periods  of  time. 

The  need  to  cui  itrol  cost  m  all  its  forms  places  the  software  engineering  process  — 
and  those  who  conduct  it  —  in  a  set  of  managed  activities  that  are  frequently  re¬ 
viewed  and  adjusted  by  those  responsible  for  the  cost  of  system  production,  system 
acquisition,  and  ownership. 

Section  4.5  discusses  the  engineering  process  and  the  process-related  constraints 
that  are  placed  on  the  engineering  activities.  The  point  to  recognize  here  is  that  the 
most  effective  methods  are  those  that  deal  with  management  issues  as  well  as 
technical  issues,  and  do  so  by  understanding  the  work  products  needed  to  support 
the  technical  activities. 

Recognizing  the  above,  it  is  apparent  that  software  developers  are  not  free  to  create  any  software 
structures,  constructs,  or  mechanisms  they  can  imagine.  Each  implementation  platform 
(hardware  and  operating/language  system)  forces  developers  in  particular  directions.  The  desire 
to  reuse  existing  software  components  limits  the  developers  even  more.  The  most  effective 
methods  are  those  that  deal  with  the  implementation  constraints.  The  methods  should  provide 
assistance  in  accurately  analyzing  and  describing  the  system  to  be  built  and  should  provide  a 
bridge  between  the  system  description  and  an  acceptable  implementation  architecture.  The 
method  should  lead  directly  into  an  implementation  made  up  of  the  entities,  constructs,  and 
mechanisms  supported  by  the  implementation  platform.  The  method  should  assist  in  defining  a 
cost-effective  testing  process.  Finally,  the  method  should  support  the  management  practices  and 
engineering  process  constraints  that  are  generally  found  in  the  engineering  process.  Identifying 
and  classifying  the  characteristics  of  the  engineering  problem  help  the  organization  identify  the 
needs  a  method  must  address. 


8.2.  Classifying  Methods 

The  previous  section  outlined  the  first  step  necessary  in  choosing  methods:  characterization  of 
.tie  engineering  problem  to  be  solved  in  terms  of  the  nature  of  the  system  to  be  built,  the  con¬ 
straints  placed  on  the  implementation,  and  the  constraints  placed  on  the  engineering  process. 
The  second  step  in  the  process  of  choosing  a  method  deals  with  the  characterization  of  existing 
methods. 
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Chapter  5  outlined  methods  as  they  have  tradu.jnally  been  described.  These  descriptions  and 
characterizations  are  useful  for  understanding  what  a  method  is  and  how  it  addresses  particular 
problems,  but  they  are  not  always  helpful  for  deciding  which  methods  apply  to  particular  situa¬ 
tions.  Useful  characterizations  of  methods  should  be  made  in  terms  of  their  relationship  to  the 
characteristics  of  the  system  to  be  built,  the  constrained  solution,  and  the  process  to  be  followed 
when  using  the  method. 

Earlier  work  in  methods  ( [Freeman  83]  and  [McDonald  85])  collectively  define  five  categories  of 
characteristics  to  be  used  in  classifying  methods:  technical,  management,  economic,  usage,  and 
Ada  compatibility.  While  we  agree  that  these  are  five  useful  categories,  for  the  purpose  of  this 
report  —  a  high-level  introduction  to  methods  and  their  selection  for  use  —  we  have  combined 
Ada  compatibility  with  technical  characteristics,  and  economic  issues  with  management  issues. 
The  following  three  subsections  deal  with  classifying  methods  in  terms  of  their  technical,  manage¬ 
ment,  and  usage  characteristics.  The  process  of  "characterizing"  concerns  itself  with  what  a 
method  is,  what  a  method  ’'res,  and  what  issues  a  method  addresses. 

1 .  Technical  ch<>  ,..ie  ..tics.  Chapter  3  discussed  various  aspects  of  the  devel¬ 
opment  process.  It  outlined  three  stages  of  development  (specification,  design,  and 
implementation)  and  three  views  of  the  system  being  developed  (behavioral,  func¬ 
tional,  and  structural).  This  high-level  view  of  the  process  can  be  used  as  a 
framework  for  classifying  the  technical  characteristics  of  a  method. 

The  characteristics  of  the  engineering  problem  to  be  solved  are  dealt  with  during 
the  specification  stage.  These  characteristics  can  be  grouped  into  the  behavioral 
and  functional  views  appropriate  for  the  specification  stage.  These  views  of  the 
problem  are  carried  forward  through  the  design  to  the  implementation  stage  where 
they  are  represented  as  the  behavioral  and  functional  views  of  the  implementation. 
Effective  methods  are  those  that  allow  smooth  transition  across  stages  and  trace 
the  functional  and  behavioral  aspects  of  the  problem  through  to  implementation. 

The  solution  constraints  are  dealt  with  beginning  at  the  design  stage  and  moving 
forward  to  the  implementation  stage.  At  the  design  stage,  the  behavioral  and  func¬ 
tional  characteristics  of  the  problem  are  mapped  to  the  behavioral  and  functional 
characteristics  of  the  solution.  The  structural  view  prescribed  by  an  effective  meth¬ 
od  is  one  that  maps  directly  to  the  functional/structural  view  of  the  implementation 
stage. 

2.  Management  characteristics.  As  stated  in  Section  5.3,  the  most  effective  meth¬ 
ods  are  those  that  deal  with  management  and  technical  issues.  When  charac¬ 
terizing  a  method,  it  is  important  to  consider  the  support  it  gives  to  management 
issues.  The  characterization  should  consider  whether  and  how  the  method  deals 
with  the  typical  management  and  project  issues  of  estimating,  planning,  review,  and 
management  of  work  products.  This  characterization  should  be  related  to  the 
needs  and  process  that  exist  within  the  organization.  Management  practices  are 
often  the  most  difficult  thing  to  change  within  an  organization.  Re'ating  a  method  to 
existing  practices  will  help  the  selection  process  by  identifying  potential  changes  in 
practice  required  to  use  the  method  effectively. 

3.  Usage  characteristics.  When  classifying  methods  for  comparison  and  evaluation, 
it  is  important  to  capture  and  describe  the  characteristics  of  the  method  that  will 
effect  its  use  by  the  engineering  organization.  Usage  characteristics  include  the 
conceptual  basis  for  the  method,  availability  of  training,  and  automated  support. 

Again,  this  characterization  should  be  related  to  the  organization  that  will  use  the 
method.  Selecting  a  new  method  often  means  a  change  in  engineering  practice. 
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The  classification  and  selection  process  should  help  the  organization  understand 
the  magnitude  of  the  change,  and  help  engineers  to  make  the  change. 

Characterizing  existing  methods  is,  then,  the  second  step  in  the  selection  process.  The  classifi¬ 
cation  should  be  done  in  a  manner  that  allows  those  responsible  for  method  selection  and  use  to 
relate  the  methods  to  the  needs  of  the  organization  as  it  develops  specific  systems. 


8.3.  Selecting  a  Method 

The  previous  sections  discussed  the  first  two  steps  of  the  selection  process:  identifying  the  needs 
of  the  organization  and  classifying  existing  methods  in  terms  of  technical,  management,  and 
usage  characteristics.  These  first  steps  set  the  stage  for  the  last  by  helping  those  responsible  for 
the  selection  come  to  grips  with  the  nature  of  the  problem  they  are  trying  to  solve  and  the  poten¬ 
tial  of  specific  methods  to  deal  with  the  problem. 

The  final  step  is  to  select  a  method,  though  this  is  not  usually  a  simple  procedure.  The  needs 
analysis  performed  as  the  first  step  of  the  selection  process  will  generally  produce  a  set  of  needs 
that  are  not  completely  covered  by  any  method.  The  process  of  selection  is  one  that  finds  the 
best  solution  rather  than  a  complete  solution.  The  following  general  activities  should  be  per¬ 
formed  in  making  the  selectio  v 

1 .  Rank  the  Issues.  Tt  first  step  of  the  selection  process  results  in  a  set  of  issues 
that  must  be  considered  by  those  producing  a  particular  system.  This  set  of  issues 
must  be  ranked  by  the  engineering  organization  to  determine  its  real  needs.  The 
ranking  should  be  based  on  the  importance  of  each  issue  to  the  particular  organi¬ 
zation  and  should  consider  questions  such  as:  How  critical  is  resolution  of  the 
issue  to  the  success  of  the  engineering  project?  How  difficult  will  the  issue  be  to 
resolve?  How  much  experience  and  success  has  the  organization  had  in  dealing 
with  similar  problems  in  the  past?  The  ranking  should  identify  problems  that  seem 
especially  difficult  to  solve  or  those  that  will  require  the  organization  to  use  unfa¬ 
miliar  techniques.  This  ranked  list  should  cover  both  technical  and  management 
issues.  Once  created,  !t  can  serve  as  the  basis  for  the  step  described  below. 

2.  Identify  key  discriminators.  The  ranked  list  of  issues  can  be  used  to  define  the 
characteristics  of  a  method  that  will  be  effective  in  dealing  with  the  engineering 
problem.  The  ra  \ed  list  should  be  used  to  define  two  classes  of  features:  essen¬ 
tial  features  and  desirable  features.  While  the  list  of  desirable  features  will  probably 
contain  items  that  address  all  the  issues,  it  is  important  to  remember  that  one  is 
unlikely  to  find  any  method  that  will  do  this.  Desirable  features  are  those  where 
there  is  room  for  compromise  —  those  that  can  possibly  be  absent  or  only  partially 
effective.  Essential  features,  on  the  other  hand,  are  those  where  there  is  no  room 
for  compromise.  This  list  of  key  discriminating  factors  can  be  used  to  quickly  weed 
out  candidate  methods. 

3.  Apply  to  methods.  Once  the  key  discriminators  are  identified,  they  should  be 
applied  to  the  classified  methods  to  determine  which  methods  have  potential  bene¬ 
fit.  The  result  of  this  process  will  usually  be  a  shorter  list  of  candidate  methods. 

The  candidates  are  those  that  possess  all  essential  features  —  features  that  deal 
effectively  with  the  critical  issues  defined  in  the  ranking  process.  Further  evaluation 
should  consider  how  well  each  method  covers  the  desirable  features.  This  is  gen¬ 
erally  a  subjective  process  that  must  deal  with  issues  not  easily  measured  and  do 
so  in  a  way  that  considers  the  culture  of  the  engineering  organization. 
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4.  Determine  undesirable  features.  During  the  final  steps  of  the  selection  process,  it 
is  important  to  consider  the  undesirable  features  of  the  candidate  methods.  Meth¬ 
ods  have  been  developed  to  deal  with  the  complexities  of  engineering  activities, 
and  each  handles  complexity  in  its  own  way.  Rigorous,  formal  specification  meth¬ 
ods,  for  example,  lead  to  problem  statements  that  are  complete  and  consistent. 

These  methods,  however,  are  often  difficult  to  learn  and  cumbersome  to  use.  Cer¬ 
tain  other  graphically  based  methods,  on  the  other  hand,  are  relatively  easy  to  use 
and  lead  to  problem  descriptions  that  can  be  understood  and  reviewed  by  wide 
audiences.  These  methods,  however,  often  lack  the  rigor  and  forma!  basis  required 
to  support  detailed,  thorough  analysis  for  a  variety  of  conditions. 

For  each  method  evaluated,  it  is  important  to  determine  the  method's  undesirable 
features.  What  issues  does  the  method  not  deal  with?  What  are  the  negative 
consequences  of  using  the  method  to  solve  a  particular  problem?  What  costs  are 
associated  with  acquiring  and  adopting  the  method? 

The  set  of  activities  described  above  brings  those  responsible  for  method  selection  to  a  decision 
point.  From  the  preceding  discussion,  it  should  be  apparent  that  the  decision  is  complicated  and 
largely  subjective.  It  involves  a  number  of  tradeoffs,  for  example,  rigor  versus  ease  of  use, 
management  support  versus  minimal  engineering  workload.  In  many  cases,  the  tradeoff  deci¬ 
sions  cannot  be  supported  with  well-defined,  objective  measurement  criteria  since  these  metrics 
do  not  yet  exist. 

The  final  decision  is  best  attained  by  thoroughly  analyzing  and  understanding  the  engineering 
problem,  the  constrained  solution,  and  the  candidate  methods.  This  understanding,  used  by 
those  experienced  in  the  development  of  real-time  systems,  supports  the  subjective  decision¬ 
making  process  that  must  occur.  The  decision-making  process  should  identify  the  best  method 
for  the  problem.  It  should  also  identify  those  issues  the  method  does  not  deal  with  and  the  costs 
involved  in  adopting  the  method.  The  data  collected  and  the  understanding  achieved  during  the 
selection  process  can  be  used  to  support  the  successful  adoption  of  the  method  selected. 
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Appendix  A:  Key  Methods  -  Acronym  Descriptions  and 
!  References 


Method 

Brief  Description 

References 

A7 

A7  Methodology 

llamas  86] 

DARTS 

Design  Approach  for  Real-Time  Systems 

[Gomaa  86] 

DCDS 

Distributed  Computing  Design  System 

[Alford  85] 

HIPO 

Hierarchy,  plus  Input,  Process,  Output 

[Stay  76] 

HOS 

Higher  Order  Software 

[Hamilton  76] 

JSD 

Jackson  Structured  Design 

[Cameron  83] 
[Jackson  75] 

MASCOT 

Modular  Approach  to  Software 

Construction  Operation  and  Test 

[Bate  86] 
[Booer  82] 
[Jackson  84] 
[Simpson  84] 

OOD 

Object-Oriented  Design 

[Booch  83b] 
[Buzzard  85] 
[Cox  84] 

PAISLey 

Process-Oriented,  Applicative, 

and  Interpretable  Specification  Language 

[Zave  86] 

PAMELA 

Process  Abstraction  Method  for 

Embedded  Large  Applications 

[Cherry  87] 

PSL/PSA 

Problem  Statement  Language/ 

Problem  Statement  Analyzer 

[Teichrow  77] 

SADT 

Structured  Analysis  and  Design  Technique 

[Ross  77] 
[Connor  801 
[Ross  81] 

SARA 

System  Architect's  Apprentice 

[Estrin  86] 

SA/SD/RT 

Structured  Analysis/ 

Structured  Design/ 

Real-Time 

[DeMarco  78] 
[Ward  05] 

SREM 

Software  Requirements  Engineering  Methods 

[Alford  85] 
[Hoffman  81] 
[Scheffer  85] 

Statecharts 

Statecharts 

[Harel  86] 

v/DM 

Vienna  Development  Method 

[Bjorner  83] 
[Jones  86] 

Warnier  Orr 

Warnier  Orr  Diagrams 

[Warnier  76] 
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